This post will provide a brief overview of the 3rd and 4th chapter of Steve McConnell’s Code Complete(2nd Edition). You may want to check out the Review of the first 2 chapters if you missed it.
Chapter 3:Measure Twice, Cut Once: Upstream Prerequisites
This chapter describes the work that must be done to prepare for software construction. It describes what proper planning entails and its vitality before and during construction. In software development, such planning is done when a problem is defined, a solution is specified, and the solution is designed. It is a no brainer that we plan to have control over things and hence avoid failure. This same principle applies to software construction. The overarching goal of planning is risk reduction: a good project planner clears major risks out of the way as early as possible so that the bulk of the project can proceed as smoothly as possible.
A common cause of incomplete preparation is that the developers who are assigned to work on the upstream activities do not have the expertise to carry out their assignments. Another reason would be that managers are notoriously unsympathetic to programmers who spend time on construction prerequisites. With these stumbling blocks in mind, Steve McConnell outlines utterly compelling and foolproof arguments for doing prerequisite before construction to help deal with bosses and managers who don’t understand the importance of preparation and prerequisites.
Furthermore, the kind of project you’re working on significantly affects construction prerequisites — many projects should be highly iterative, and some should be more sequential. The net impact on construction prerequisites is that you should first determine what construction prerequisites are well suited to your project. Some projects spend too little time on prerequisites, which exposes construction to an unnecessarily high rate of destabilizing changes and prevents the project from making consistent progress. Some projects do too much up front; they doggedly adhere to requirements and plans that have been invalidated by downstream discoveries, and that can also impede progress during construction.
McConnell further describes the construction prerequisites which include; problem-definition prerequisite, requirements prerequisite and architecture prerequisite. A problem definition defines what the problem is without any reference to possible solutions. The problem definition should be in the user language, and the problem should be described from a user’s point of view. It usually should not be stated in technical computer terms. Requirements describe in detail what a software system is supposed to do, and they are the first step toward a solution. Software architecture is the high-level part of software design, the frame that holds the more detailed parts of the design. Having architecture as a prerequisite is important because the quality of the architecture determines the conceptual integrity of the system that in turn determines the ultimate quality of the system.
…
Chapter 4: Key Construction Decisions
Once an appropriate groundwork has been laid for construction, preparation turns toward more construction-specific decisions. This chapter focuses on preparations that individual programmers and technical leads are responsible for, directly or indirectly.
First and foremost, the programming language in which the system will be implemented should be of great interest to the programmer since they will be immersed in it from the beginning of construction to the end. Studies have shown that the programming-language choice affects productivity and code quality in several ways. Programmers, for instance, are more productive using a familiar language than an unfamiliar one.
Concerning programming conventions, architectural guidelines give the program structural balance and construction guidelines provide low-level harmony, articulating each class as a faithful part of comprehensive design. Before construction begins, programmers need to spell out the programming conventions they’ll use as they are difficult to change in the later stages of construction.
The book further explains how the position of a programmer on the technology wave determines what approaches will be effective — or even possible. It is essential to identify where you are on the technology wave and adjust your plans and expectations accordingly. Awareness of the location of the technology wave helps programmers decide on the approaches to take and what to focus on in their projects.
The author brings this chapter to a close by summarizing the specific practices software engineers should consciously decide to include or exclude during construction.
To sum up, these chapters establish the importance of careful planning before construction and making crucial decisions before embarking on construction. See you on the next one!