Code Complete review 1: Laying the Foundation

The first thing I have to say about the book is that it is huge and, coming from someone with a physical book, it is kind of uncomfortable to even read it but, coming from a book called Code Complete, it is kind of expected.

Setting those details aside, I’ll focus on the content and also I’d like to include some of the notes I took as a summary and reminder for myself in the future, but I hope it might help you too.

So, moving to the content, the book itself is grouped into seven parts, using that as a reference, this post series will be divided into seven parts.

LAYING THE FOUNDATION

1.1 Welcome to Software Construction

When we think of construction, several different things can come to our minds: a house, a building, a robot, or more; But, if we think only about the meaning of the word, the word itself refers to building something.

In software development, construction refers to writing code or programming.

Even thought construction is important, is not the only activity involved in the development of a software project.

The reason we focus on construction is that, even when there are other important activities, construction is the only activity that’s guaranteed to happen on every project.

1.2 Metaphors for a Richer Understanding of Software Development

Metaphors help you to get an idea by using concepts and topics that you are more familiar with. There are no wrong metaphors, but some are better than others, and they keep changing for better ones.

In software development, we use metaphors all the time and for everything; to get answers, for teamwork, to understand others and others can understand us. Objects, bugs, architecture, buttons, network, and many more, in case you haven’t noticed, all of them metaphors! even writing code is a metaphor.

Everyone has a different vision, and because of that, everyone has a different metaphor to speak about software development.

The metaphor we will be using is building. Building has different stages: planning, preparation, construction, and execution. A big project will require more planning than a small one, and that applies to the other stages too: the amount of work depends on the size of the project.

While a metaphor might be helpful to understand something, that doesn’t mean it is the only one we should be using. In fact, metaphors are not exclusive and can be combined depending on the scenario: what matters is that you and the others are able to understand the message.

1.3 Measure Twice, Cut Once: Upstream Prerequisites

Following with the construction metaphor, before construction, workers make sure to have everything ready to start. Depending on the size of the project, planning will be different.

When you focus on quality at the end of the project, you are focusing on testing. Testing makes sure that what you deliver is working, but it can’t detect flaws like building the wrong product or building the right product in the wrong way.

When you focus on quality in the middle, you are focusing on construction. Quality on Construction is the main focus of the book. It can’t detect flaws like building the wrong product.

When you focus on quality at the start, you are focusing on planning. Quality in the planning phase makes sure that what you plan for is what you get.

Sometimes planning doesn’t get the importance it deserves, so to understand and make others understand, we can use three different arguments:

Logic, it makes no sense to build something just to discover that isn’t what you wanted.

Analogy, building software is like any other project, before starting you need the blueprints.

Data, it is 10 to 100 times cheaper to fix an error in the planning phase than it is in later phases.

There are different prerequisites before construction starts.

Before starting construction, we must have clear "what is the problem to solve". The problem definition should be simple and on user level.

Based on the problem, the requirements are written. Requirements describe in detail what the system should do. Requirements tend to change and the reality is those changes can happen in later stages of building. If those changes are not handled properly, this will have a negative impact and, for that reason, we have some advice for you:

• If you have doubts, stop and confirm the requirements
• If requirements change or new ones are added, always remind the requester of the cost in time and money that any change means.
• If changes are a must, always have a priority control to keep a record over the changes so clients will know that their changes will be worked on at some point.
• Use development life cycles with a short cycle: this will allow you to make changes and get feedback quickly.
• If requirements are bad or out of control, think if it is worth to keep working on that project and the pros and cons of staying: sometimes the best is to move on to the next.
• As an extra, always keep in mind your client and their business, in that way you can give feedback for better requirements and decisions.

And then, the architecture. In this stage, the design and implementation is detailed. A good or bad design has a great impact on the overall quality of the system, and it works as a base for both client and developers.

1.4 Key Construction Decisions

Once prerequisites for construction are completed, we can start with construction itself but, before anything, we need to make some decisions. You can compare this with choosing the right tools to make the work.

Choosing the right language; there are different kinds of languages and each is used in a different environment so, besides going for something that better suits your project, you need to consider yourself and your team. By choosing a language in which you have interest and experience, productivity is greatly increased.

Choosing programming conventions; again, choose what you think suits your project. Conventions will allow you to keep order and control over the project. The recommendation here is that you should pick your conventions right before starting with construction and stick to them; changing conventions in the middle of construction can become a nightmare.

Choosing (good) construction practices; reality is that right now there are many available good practices and some of them even contradict themselves so, don’t worry about trying to follow all of them; just pick some and emphasize the usage on your project and team.

Closure

In the personal side of this, while reading this I related with many of the scenarios described as a consequence of a lack or bad planning. Even if I learned from experience, I think is great to have a source of information besides my own thinking; not only to avoid repeating the same mistakes but also to teach those around you, including peers and clients, about a proper way to do things. Giving a source of information sometimes is better than saying "because I say so".

And this concludes the first part of this review. I hope this helped to give you some ideas and even generate some interest to take on the whole book.

Stay tuned to read the upcoming reviews of this book.