Code Complete 2: Prerequisites and Key Construction Decisions (Part 2)

What is a prerequisite, you might be wondering? For those without a dictionary nearby, a prerequisite is a thing that is required as a prior condition for something else to happen or exist. Before building a house or a skyscraper there is some kind of professional preparation that a builder undertakes depending on the type of project. As with building construction, much of the success or failure of a software project has already been determined before construction begins. In the third chapter of his book Code Complete Second Edition, Steve McConnell dives deep into what must be done to prepare for software construction.

For any high-quality software, the programmers have to use high-quality practices at the beginning, middle and end of a project. Emphasizing quality at the end of a project means you emphasize system testing, which as opposed to many peoples’ thoughts is only one part of a complete quality-assurance strategy, and it’s not the most influential one. The downside of this is that testing can't detect a flaw such as building the wrong product or building the right product in the wrong way. Emphasizing quality in the middle of the project, means you emphasize construction practices. Emphasizing quality at the beginning of the project means you plan for, require and design a high-quality product.

Even with the importance of preparation in mind, programmers still do not check that prerequisites have been satisfied before jumping into construction. The reasons for this include; the programmers assigned to work on upstream activities (e.g architecture, design and project planning) do not have the expertise to carry out the activities, other programmers know how to perform these upstream activities but they do not prepare because they can’t resist the urge to code as soon as possible and finally managers are notoriously unsympathetic to programmers who spend time on construction prerequisites. Steve McConnell further 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.

It is important to note that different kinds of software projects call for different balances between preparation and construction. Iterative approaches have an effect on preparation and the book provides a very vivid explanation for this. It further outlines the thing to consider when choosing between an iterative or a sequential approach for a project.

There are several specific construction prerequisites. The first prerequisite you need to fulfil before beginning any construction is a clear statement of the problem that the system is supposed to solve (also known as “product vision”, “vision statement”, “mission statement” or “product definition”. The second prerequisite is requirements prerequisite. Requirements describe in detail what the software is supposed to do and they are the first step towards problem-solving. Requirements are important because they help to avoid arguments and help to minimize changes to the system after development begins. Stable requirements is a myth and there should be mechanisms to handle requirement changes during construction. Architecture prerequisite is another important construction prerequisite. 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.

Problem definition lays foundation for the rest of the programming process
The problem definition lays the foundation for the rest of the programming process (Steve McConnell)

The fourth chapter titled “Key Construction Decisions”, is a relatively small chapter that focuses on the preparations that individual programmers and technical leads are responsible for, directly or indirectly. The chapter gives insights into the tools that one needs before commencing software construction. Deciding on the right programming language, for instance, affect the programmer's productivity and code quality in several ways. The choice of programming language should be interesting to you as you will be immersed in it from the beginning to the end of construction. Studies have shown that programmers are more productive using a familiar language than an unfamiliar language (obviously!).

Another construction decision one needs to make is on programming conventions. Before beginning construction, highlight the programming conventions to use as they are difficult to change in the later stages of construction. As a programmer, you should be aware of your location in a technology wave. What does that mean you ask? At the end of a technology wave programmers benefit from a rich software development infrastructure, that is, there is numerous programming language choice with comprehensive error checking, powerful debugging tools and automatic, reliable performance optimization. In early-wave environments the situation is opposite; few programming language choices available which tend to be buggy and poorly document. 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 goes ahead and notes that your programming tools don’t have to determine how you think about programming. There is a difference between programming in a language and programming into a language. Programming “in” a language limits thoughts to constructs that the language supports directly (if a language is primitive then the programmer’s thoughts will be primitive) while programming “into” a language means first deciding what thought you want to express and then determine how to express them using the tools provided by the specific language. Lastly, as a developer, you should be equipped with relevant skills to decide on which of the many available good practices you’ll emphasize on.

In summary, the two chapters highlight the importance of having prerequisites before beginning your software construction. After identifying your prerequisites and preparing for them, you need to make key construction decisions before jumping into the construction process. Just as in building construction a builder needs blueprints, permits and a survey of the house foundation and select specific tools to load their trucks before heading out to the job site. See you in part 3 of this series!