Simplicity, The 5-Minute Rule and the Refactoring Effort Measure

June 16, 2006 — Posted by Al Shalloway

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 ):More...

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.

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.



        

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban