This is the second post in my series on Code Complete, covering my notes and commentary from Chapter 3, Section 2. The title of this section is Measure Twice, Cut Once: Upstream Prerequisites.
Essentially, this section is talking about the importance of developing prerequisites before beginning work on a project. It reminds me of a phrase that was apparently one of Frank Lloyd Wright’s favorites:
The architect’s two most important tools are: the eraser in the drafting room and the wrecking bar on the site.
Frank Lloyd Wright
In Software, this is equally applicable. The easier that we can catch defects, from design to development to production, the easier they are to fix. Obviously, in Wright’s quote above, using the eraser would be significantly cheaper than using a wrecking bar.
Much of the success or failure of the project has already been determined before construction begins.
S. McConnell, Code Complete, second edition. Redmond (Washington): Microsoft Press, 2004.
The diagram below is one that I created for a presentation given at Etsy – it’s a very generalized diagram, not representative of any actual set of data. However, it gives an idea of the relative cost to fix defects that are introduced during the software development process.
This section in Code Complete features a similar diagram – but backed by more solid data. Essentially, the earlier that defects are detected and corrected, the cheaper they are to fix.
…debugging and associated rework takes about 50 percent of the time spent in a typical software development cycle…
S. McConnell, Code Complete, second edition. Redmond (Washington): Microsoft Press, 2004.
So really, the whole point of this section is that planning reduces the overall cost of software development. Of course, this doesn’t mean that we should do everything in a waterfall approach and attempt to plan everything before we even start coding. We have to strike a balance between the two.
I believe, when using Agile methodologies, we should ensure that we plan carefully for the features that we’re focusing on building. Whether you’re using sprints or not, you can plan ahead for the work that you’re doing to ensure that you’re minimizing the ‘rework’ required.
It’s by striking a balance between planning too much and planning too little that we can be most effective in our software projects.
If you start the process with designs for a Pontiac Aztek, you can test it all you want to, and it will never turn into a Rolls-Royce.
S. McConnell, Code Complete, second edition. Redmond (Washington): Microsoft Press, 2004.
Leave a Reply