Code Complete Review – Chapter 1: Welcome to Software Construction
Welcome to the first installment of my review of Steve McConnell’s influential text Code Complete (2nd Edition). If you haven’t already, please first read my Introduction to the Series post, it’s short I promise! In this post we will dig into the content and get started with the first chapter. I hope you enjoy it!
The first chapter briefly discusses the various tasks involved in software development and highlights which of these will receive the most focus in this book. In a nutshell, the purpose of this chapter is to lay the groundwork for what you will learn by reading Code Complete.
Let’s start with the full list of software development activities:
Many people, particularly those coming from a more “informal” programming background, consider the construction phase to be at the core of software development. For the most part, McConnel agrees that this is an accurate assumption with the caveat that it is still important to understand the important roles the other nonconstruction activities play. However, he emphasizes that the rest of the book will heavily focus on the construction related activities, saying:
If this book were a dog, it would nuzzle up to construction, wag its tail at design and testing, and bark at the other development activities.
More specifically, Code Complete will focus primarily on the following software development activities, ordered by degree of emphasis:
- Coding and debugging
- Detailed design
- Construction planning
- Unit testing
- Integration testing
McConnel finishes off the first chapter by discussing in broad strokes why construction plays such a vital role in software development.
Your understanding of how to do construction determines how good of a programmer you are.
First, construction takes up a huge chuck of the total time spent on a project (30-80%). It is also a “central activity in software development,” with the other tasks largely occurring before (requirements and architecture) or after (system testing) the construction phase. He also notes a few studies that show an increase in productivity when programmers are focusing on software construction.
Additionally, source code, which is the result of construction, is often the best (and sometimes only) documentation that remains up-to-date, and thus should be crafted with care. Finally, he points out that construction is the only activity “that’s guaranteed to be done,” considering the reality of time-constraints, budgets, unexpected errors, and other issues which often eat into the goals of "ideal project" expectations. In these situations, it is generally the nonconstruction activities that are trimmed from the project because the construction itself is mandatory. Thus, by improving the construction phase, you effectively improve the whole project!
This wraps up my brief review of the first chapter.
About the Author
I'm a clinical psychologist, informaticist, developer, crypto-enthusiast, and incurable tech junkie.