At refactr
we believe in the value of connection, the
utility of agile processes, and the power of great ideas.
We are creating the next generation of software for
people who expect more from their web applications.
« Agile FUD? | Agile’s Dark Side »
The Appropriate Amount of Time for Discussion
I have been on too many projects where the discussions went way overboard (many times through my own causing.) It is so easy to fall into the trap of “let’s just discuss it quick” and one hour later still be debating the finer points of a relatively minor architecture issue. The truth of the matter is this happens more frequently for teams that don’t do pair programming. When pairing is used, the discussions tend to be shorter and you are generally still working while you are debating. So the question is, how much time should “discussions” take?
Here is a simple scorecard you can use to figure out if you have beat-the-horse-dead.
Tally your total points and see below
| Give Yourself | Your Score | If this is true |
| +1 | if your topic depends or directly affects a number of external entities, 3rd party clients, or executives not normally associated with your group. | |
| +1 | if your decision is permanent or nearly permanent, e.g. Hiring and Firing, purchasing hardware, building out a physical space to a new more agile layout, etc. (notice nothing relating to software construction) | |
| +1 | if your decision is about refactoring legacy code with no tests where the primary maintainer sadly passed away in ‘98 from old age | |
| +2 | if your domain is medical devices, banking, or uses HIPAA data | |
| -1 | if your application is a social networking site for 6th – 12th graders | |
| +1 | if the company owner is in the room and you know happens to be a big RUP guy | |
| -1 | if there is a design pattern that has already solved your problem | |
| -1 | if your application has never been deployed to production | |
| TOTAL: | ||
Now take your TOTAL answer and multiply it by 10 minutes. In the absolute worst scenario the discussion should only take 60 minutes.
If your TOTAL was zero or negative, you should be doing more development and less “discussing.” As a rule of thumb you should limit all design conversations to ten minutes, anything over is waste. If you find your conversations are getting out of control try some of these tactics to reel them back in.
- If you aren’t already pairing, do so. Sit down and pair for a few hours. You will get so much more done than having a 30 minute debate about if you should use polymorphism or delegation.
- Start a team decision maker baton. When you get hung up in a debate, it is the person holding the baton’s job to step in and make a decision. After the dispute is settled pass the baton to a new team member to solve the next problem. This way everyone at some point will be the final decision maker which will foster collective ownership.
- Remember winning the battle doesn’t mean you are winning the war.
- For 90% of you, relax and remember, you are just building a social networking app for teens. It isn’t pace maker firmware.
- Cite actual evidence; show patterns or examples of others in the industry that are doing it like you are proposing.
- Take precedence of a solid object model that represents your domain and reduces your complexity *** (I highlight this one because I think people sometimes take exception to it. Some argue if you spend time on a “solid object model” you are building more than you need right now. I argue it is generally as easy to build it the “right” way than to piece it together the wrong way. When there is a significant difference in time (hours) between “ways” choose the faster, (and I know this is many times at the heart of debate). If they are pretty close in time, (within hours) choose the one that reduces and cleans up your model. Performance should not come into consideration at all at this point.)
- Tell your partner this time we do it his way if next time he promises to do it your way.
I hope these few simple tips will help you save time and headache in your next design discussions.
This entry was posted by Casey on Monday, September 18th, 2006 at 1:49 am and is filed under Agile Processes, Business, Software Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
Subscribe to weblog
This is a great post! We’re all guilty at times of over-debating issues that, in the end, don’t really matter that much. My Dad worked in construction and had a saying that helped reel in perfectionism (similar problem to these endless design discussions): It ain’t a piano. The point being that nothing they were working on was as finely tuned as a piano and so they didn’t need to get it that perfect. Maybe the agile community can take on “It ain’t a pacemaker” as our reminder that we don’t need to make it perfect. ...on September 18th, 2006 at 12:39 pm