Developer Habits – Net Objectives Thoughts

Migrating the blog: Scott Bain

Thank you for joining us on this journey!

You may know that Net Objectives has joined with Disciplined Agile and is now part of the Project Management Institute. Here is the press release: https://www.pmi.org/about/press-media/press-releases/project-management-institute-announces-acquisition-of-flex-from-net-objectives

As part of this migration, Scott is now blogging on ProjectManagement.com. Here are the addresses of his blog:

We invite you to join in following him on that site.

On 30 September, the Net Objectives Thoughts blog will be officially closed.

If you have any questions, please contact Scott at scott.bain@pmi.org

Shalloway’s Law and Shalloway’s Principle

This blog was first written in August 2007

A few years ago somebody came up to me in one of my classes and said, “you’re the CEO of a successful company, co-author of a successful book (Design Patterns Explained: A New Perspective on Object-Oriented Design), … you ought to have something named after yourself.” So I, of course, immediately like this guy and think – hmm, what should that be? I came up with this:

Shalloway’s Law:

“When N things need to change and N>1, Shalloway will find at most N-1 of these things.”

Hey, I didn’t say it was complimentary. It’s a law! I have to follow it. That’s the problem. BTW: They didn’t ask me about gravity either when I was born! I really would like to break that law at times too!

Eventually I came up with Shalloway’s Principle:

“Avoid situations w

So I came up with Shalloway’s Principle:

“Avoid situations where Shalloway’s Law applies”

Shaloway’s law applied when “N > 1″ and Shalloway has to find all of the things involved. In other words, avoid redundancy (make N=1) or make it so Shalloway doesn’t have to find the things. For example, I may have redundancy in my interfaces. But I also have a cool “to do list generator” (some people call it a compiler) that when I change a method’s interface it tells me what I need to update. Better not to have redundancy at all, but if you do, make sure Shalloway’s law does not apply.

For an in depth view of this, see Shalloway’s Law and Shalloway’s Principle from Essential Skills for the Agile Developer: A Guide to Better Programming and Design.

TDD “Good” Tests Part 3. There must be no other test that fails for this reason

When organizations adopt TDD as their development paradigm, early results can be quite good once the teams get over the initial learning curve. Code quality goes up, defect rate goes down, and the team gains confidence which allows them to be aggressive in pursuing business value.

But there is a negative trend that can emerge as the test suite grows in size over time. Continue reading “TDD “Good” Tests Part 3. There must be no other test that fails for this reason”

Agile Developer Habits 101 – How Will I Know I’ve Done That

I have learned that developing good habits is key in improving my abilities. A series of good small decisions can often prove to be better than infrequent good ones. The most effective way to develop a habit is to have a trigger for it. That is, when an event occurs, do the thing you want to. Otherwise good habits just devolve to good ideas that don’t happen.

One good habit is to validate you understand something that someone has requested of you. In this case our trigger can be a request. The habit is to validate it by asking them what their acceptance criteria is. This doesn’t mean that they are right in their criteria – people often ask for the wrong thing. But a critical first step is to ensure you understand what they asked for.

Habit – validate understanding.

Trigger: When someone asks you to do something.

Action: Ask – “how will I know I’ve done that?”

Intention: Validate that what they say matches what you heard.

Habit – understand their why

Follow up Action: Ask – “and why do you want that?”

Intention: Validate you understand their objective as their might be a different way to achieve that.