It should be emphasized right from the start that this book does not teach how to create software. It does, however, attempt to teach how to create software well. Assuming the reader is a fairly experienced programmer with at least a few programming languages under his or her belt, the book covers a staggering area that includes good requirements and design specification, how to weigh competing goals, software testing, and how to use all of the different programming language features in a way that promotes readability and maintainability. There is even a chapter on personal character!
More than anything, the book drives home the message that the over-reaching goal of software design is managing complexity. The goal is always to create abstractions and modules that allow developers to focus on as small segments of the code as possible at any given time. A number of interesting design metrics are introduced and the book covers virtually all ways that code can be structured, and comments on different approaches from a variety of perspectives.
The book relies heavily on scientific studies of real-world software development projects to determine what practices work best, exposing highly interesting statistics about the efficiency of different development and testing approaches. Usually pragmatic in his advice, McConnell emphasizes readability over “clever code”, and explains his preference for making simple designs and document them well, over complicating a design to maximize run-time performance or future flexibility. The importance of doing things right from the start, as opposed to leaving bugs and design quirks for discovery further down the chain when they are an order of magnitude more expensive and difficult to fix, is emphasized repeatedly.
While reading through the book, I found the majority of advice to be self-evident, much of the rest to be highly interesting and thought-challenging, and a small portion to question whether it was I or McConnell that had gone completely crazy. Some of advice in the latter category is cleverly left in a somewhat religious, isolated chapter about coding layout and style which the authors recommends avoiding if you have high blood pressure. The code samples in the book are in C++, Java, C#, and Visual Basic, largely evenly distributed among the languages except for samples in C# which is a recent addition to the book with this second edition.
I had high expectations for this book and found them largely satisfied. I did not really expect the book to provide revolutionary new insight, and it doesn’t — what it does offer are many bits and pieces that are valuable when combined. Most of the issues touched on are things that I had previously thought about at one point or another, but I found it highly satisfying that so many of them were listed in this book together with in-depth investigations and argumentation.
I would like to have seen a little more in-depth treatment of some topics, like software testing in general and unit testing in particular — however what’s there is still plenty, and the book ends with a comprehensive bibliography for further reading. All in all, I consider this money well spent.
