Code Complete: A closer examination (Chapter 3 and 4)

Hello, this is a continuation of Chapter 1 and 2. Let’s dive right in, shall we?

Chapter 3: Measure Twice, Cut Once: Upstream Prerequisites

In this chapter, the author talks about upstream prerequisites and their importance in software construction. No matter what the project, the preparation is tailored to the project’s specific needs and done conscientiously before construction begins.

What is the importance of prerequisites?

A prerequisite is a condition of enrollment that is required to meet in order to demonstrate readiness for enrollment in a course or program

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.

Personally, this is a holy grail when I start developing any piece of software anywhere. You have to understand what the problem entails before you actually start working on a solution.

What are the causes of incomplete preparation?

Some of the common causes of incomplete preparation, according to the author, include: the software developers lack the expertise to carry out their assignments, can’t resist the urge to begin coding as soon as possible, and managers are notoriously unsympathetic to programmers who spend time on construction prerequisite.

Like any other developer, I have often encountered these problems myself. I have however come to realize the importance of not being over-excited when working on software because you are almost likely to be hit by some reality check.

Why do prerequisites before construction?

It is important to understand what the system is supposed to do and how it’s supposed to do it.

Planning means understanding what you want to build so that you don’t waste money building the wrong solution and also avoid spending all your money on building the wrong thing.

I enjoy catching a bug right before it happens. But I like it even better when I anticipate the bug. It is a key skill that enhances my work rate. It is achieved by knowing what the problem entails first.

How do iterative approaches affect prerequisites?

The author also speaks about iterative approaches and how they shape the prerequisites of a project.

Iterative approaches reduce the overall costs as compared to sequential approaches that depend highly on the testing phase in order to produce outcomes. Some of the common rules for handling these approaches include

  1. Specify ~80% of the requirements upfront: then handle the additional ones later
  2. Specify the most important 20% of the requirements upfront then handle the others in increments later

I personally like rule number 1 because it is more flexible in the long run. Having to state 80% of the requirements requires holistic thinking, which is important.

How do I choose between iterative and sequential approaches?

Choose sequential approaches when the project contains little risk, it’s stability can be predicted and the cost is likely to be high downstream

Choose iterative approaches when the design is complex, the project involves high risks and the predictability is not very important

Problem definition prerequisite

You need to have a clear statement of the problem before you begin software construction.

A problem definition defines the problem explicitly, without mentioning any solutions whatsoever.

Requirements prerequisite

Requirements describe in detail what a software system is supposed to do. They are the first step toward a solution.

It is important to have requirements in the software construction process because they help ensure that the user drives the system functionality, avoid arguments when discussing the scope of the project and also minimize changes to the software after development begins

How do we handle changes to requirements during construction?

Changing requirements midway is normally an indication of failure when describing the requirements, or a change in the end user’s mind.

I personally detest changing requirements midway. Having a clear plan on handling changes to requirements is key. The author gives us a few pointers on how to handle that, by doing the following:

  1. Check and review the requirements at the end of the session to assess the quality of the requirements
  2. Make sure everyone knows the cost of changing the requirements
  3. Make a change control procedure (for example a change control board)
  4. Dump the project if the requirements are bad

I personally do not like abandoning a project, so I would go for number 3, which triumphs over all the others.

Architecture prerequisite

Software architecture is the frame that holds the more detailed parts of the design.

Architecture is important because good architecture makes construction easy. The time taken to fix an architecture error is less than the time taken to fix a coding error.

The author proceeds to inform us about the components that comprise a good system architecture, which include program organization, major classes, data design, business rules, error processing, and many more.

The most important to me is the program organization component. The architecture should define the major building blocks in a program and split them into simple and small logical pieces that have one area of responsibility.


In summary, prerequisites are an important part of software construction. The author has done an amazing job when it comes to carefully explaining the various types of prerequisites, and their importance in software construction. My favorite part of this chapter is when the author explains what to do when changing prerequisites mid-construction.

Chapter 4: Key Construction Decisions

In this chapter, the author speaks about the key decisions that are to be made when doing software construction.

How do we choose a programming language for a project?

We should choose programming languages that are of interest to us and also ones that we are familiar with. The language should not affect our thinking when it comes to development.

The author mentions the importance of having programming conventions before any construction begins. This is especially important when developing software as a team. It really nudges every team member to write code that everyone can understand easily.

The author also mentions the importance of programming into a language by compensating for the lack of programming constructs in a language by inventing custom conventions.

How do you select construction practices?

When selecting construction practices, it is important to have a clear construction checklist which should be followed accordingly. Some of these include:

  1. Coding practices such as naming conventions, coding practices, and project layouts
  2. Teamwork practices such as integration procedures, pair programming
  3. Quality assurance practices such as test cases before writing code, unit testing, and peer reviews

I personally love the last one(number 3) because it is a very important practice which I use every day.


The author has done a great job of pointing out the importance of having construction decisions on the ready before you start software construction. I personally liked the idea of having a checklist of the practices to be followed during the construction process. I agree with the author on the idea of programming into a language. It is important to be aware of the shortcomings of a language so that you can learn how to compensate for that.

Also, check out my Chapter 5



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store