Hey, my first international blog. I'm in Copenhagen for the next week and Ireland the next doing a couple of Design Patterns and Advanced Software Design courses.

I have always been a fan of simplicity. While I am careful to remember H.L. Mencken’s great observation – “For every complex problem there is a simple solution… and it is wrong!” – it seems in software development, we tend to make things more complex than is needed.

So, it was with great enthusiasm that I read Jack Trout’s book, The Power of Simplicity: A Management Guide to Cutting Through The Nonsense and Doing Things Right. If you haven’t encountered Jack, he is the co-author of one of my all-time favorite marketing books, Positioning: The Battle for Your Mind.

It got me thinking about a rule I use on my projects to help keep things simple. I call it “The Five Minute Rule”*. It is really pretty simple ):

If developers are having a conversation about the merits of two different designs (a conversation that unfortunately often turns into a religious one), I request they put a limit of 5 minutes on the conversation.

Why does this work? Because if two, level-headed people, are committed more to the better result than their own egos, it shouldn’t take more than five minutes to resolve the conversation. If, after five minutes, the conversation is still raging (and assuming it has kept its focus), it often means that one of them is discussing the situation as it is while the other is discussing as it might be. Or both of them are discussing things as they each think it might be, but just imagining different “might be’s.” (I am assuming the people involved are not arguing for ego’s sake and that they have fairly similar understanding of the problem.)

Now, everyone I know is what I like to call “pre-cognitive impaired.” That means that they don’t see things before they happen. Like me, most of them are post-cognitive. That is, they see things after they happen. Most people who are successful in business are post-cognitive. It’s hard to be successful in business if you aren’t. (Of course, there are many people who are not post-cognitive in their personal lives; they tend to struggle through the same types of relationships over and over and wonder why they can’t be happy.)

Without pre-cognition, speculations about what might happen are not terribly productive. Therefore, after the five minutes have lapsed, I tell them to do whichever solution would be easier to implement. Scott Bain, one of our design patterns instructors, prefers to tell them to do whichever solution is easier to test. I like this, too.

Now, often developers do not like doing things just because they work; they want to know why they work. So I also talk about “Refactoring Effort Required”. Refactoring Effort is the amount of work required to go from where you are to where you want to be in refactoring your code. Sometimes a simple refactoring is all that is required; other times, it takes a big refactoring. If people are arguing about two solutions, the most time they can gain is the Refactoring Effort. Thus, if the Refactoring effort is only 30 minutes, then it is silly to discuss the alternatives for an hour. When people realize that the actual damage of making the wrong decision is minimal, they tend to not engage in unproductive conversations as much.

OK, I am admittedly, over-simplifying the problem here a little bit, but you get the idea.

More blog entries coming up. :)

* Note: I am not certain, but I suspect I got this from Ron Jeffries who claims to have gotten it from Kent Beck. My rule is a bit different from theirs (not better, different) in that they say if you can't resolve it, do an experiment. It is also important that the two do the experiment together, so their is joint learning. I think this is a great idea if the refactoring effort is significant. If it isn't, it really doesn't matter which you do.