Don’t Fix that Bug (or at least not yet)Posted on June 17th, 2009 2 comments
What does a microwave oven and a job in software development have in common? They both offer a means of near instant gratification. When comparing to other engineering disciplines, civil engineering for example, the time to closure on a project can be enormously shorter. Immediately someone will quote the development cycle for Windows Vista, cite Fred Brook, or quote a passage from “Death March”, but these focus on the grander project scale and not on the individual developer sense of accomplishment. The time from inception to implementation can be remarkably short when we examine thinks on a micro (and not macro) scopic level. Implementing a lock manager may be a part of the overall system, but it an achievement in its own right.
This immediate sense of gratification can be addictive. Combine this with the direct consumer contact in open source projects and you can see why many developers fall into the trap of being directed by bug reports and not overall system evolution. There is a time in the development cycle to fix bugs, and there is a time to focus on pushing features forward. There are times when refactoring a component will address bugs and add functionality. However, as a general rule the bug fix phase and the feature work phase should be partitioned into separate cycles.
To put this another way, don’t clean your room when you should be writing your history report.
– Cheers, Jerry