CODE COMPLETE: A handbook of programming techniques
Chapter 3: Measure Twice, Cut Once
Continuation of insights gained from reading code complete. This is a summary of the knowledge gained in third chapter of the book.
In this chapter, Steve McConell lays the groundwork for successful software construction. He describes the work that must be done to prepare for software construction.
In any project, much of the success or failure is already determined before execution begins. In software development, it's therefore imperative to ensure the foundation is well laid out before actual software construction begins. If the foundation is poorly laid or planning is inadequate, the best you can do while constructing anything is keeping the damage to a minimum.
Software quality should be emphasized at the beginning, middle and end of any software project. When it comes to software quality assurance, most people emphasize on software testing. This is indeed a good practice however software testing is not the most influential part of software development. Software testing limits testing to what has already been built and not what should have been built. The most common risks in software development are poor requirements definition and poor project planning. Limiting software quality assurance to the software testing stage might not help in easy identification of risks present in the requirements definition.
Steve McConnell explains the importance of planning from three appeals. First, an appeal to logic. Technically, planning means understanding what you want to build so that you don't spend a significant amount of your time doing the wrong thing. Some times users aren't sure what they want so planning helps understand what needs to be done. Many a times preparation is rarely done in software construction and if it's done it's not executed in the right way. As programmers, it's always tempting to jump right into writing code without doing any planning. The nudge to immediately open your editor and code once you think of what might be the solution to the problem at hand is irresistible. This works well for small projects as it's easier and cheap to fix any risks encountered as you develop. For large projects, this approach however might not work as handling the risks is expensive. Discovering you've built a piece of shite that the customer won't accept at 100k lines of code is heart wrenching.
Second, an appeal to analogy. Here, software development can be thought of as a food-chain. A contamination at any level of the food-chain transcends further down the entire food-chain and might cause undesirable damage to the species affected. Poor requirements definition or incompetent planning before software construction is contamination to the software food-chain. The end result is programmers building a product riddled with untold risks.
Thirdly, an appeal to data. Studies over time have proven that it pays to do things right the first time. Unnecessary changes are expensive. Errors should be identified as soon as possible to the time at which they are introduced in the system. The more an error stays in the software food chain, the more the damage it costs further down the chain.
When planning for software construction, it's also importart to determine the kind of software you're working on. Different kinds of software projects call for different balances between preparation and construction. The cost of fixing risks however is always the same regardless of the approach chosen if adequate planning is not done before construction begins.