A Classic Revised

Steve McConnell's <i>Code Complete</i> updates and confirms some tried and true approaches —and adds some new thoughts — on software construction.

• By Mike Gunderloy
• 09/28/2004

There were several years during the late 1990s when I literally lived on the road, traveling from customer to customer in an RV. The limited space I had available forced me to cut my software book library to the bone. One of the few books I took along was Steve McConnell's Code Complete (Microsoft Press). I still have my fourth copy of the book (the other three having been swiped by enthusiastic coworkers or clients). Now, a dozen years after its first publication, there's a new, second edition of Code Complete available. That makes this an appropriate time to revisit this title, and explain why I still recommend it to every developer I know.

The Joy of Construction
As the word "code' in its title suggests, this book focuses on one particular part of the developer's craft: writing source code. The subtitle makes things even more clear: "A practical handbook of software construction." McConnell's task is simple: to teach you everything there is to know about the nuts and bolts of writing high-quality source code. You won't find any coverage of design or test activities except as they impinge on the construction process (for example, there's plenty on finding defects as part of a development team, but nothing on running a QA department).

The notion of construction is central to McConnell's thinking about software. When you use construction as your organizing metaphor, you realize that any reasonably-sized program is made up of smaller components arranged in a particular way. You understand that some design is necessary to get the desired end product. You know that defects in the foundation can be expensive to correct when found at roofing time. And you see that craftsmanship is important if you want to deliver a high-quality product.

More Info Code Complete, Second Edition By Steve McConnell Microsoft Press, June 2004 960 pages, ISBN 0735619670

Plenty of Basics
This book assumes that you know at least something about programming, but it doesn't assume you've really thought much about the process. You'll find chapters covering very basic concepts; data types, control structures, code formatting, and so on. Along the way McConnell delivers numerous recommendations on best practices (there must be thousands of them in this 900-page book) and anchors as much as he can in published research with hard facts and figures.

Even if you do know about writing code, you'll learn new things here. Which new things depend on where you are in your career. I remember the first edition teaching me about coupling and cohesion, useful concepts that I ran across for the first time in these pages. The new edition gave me the information that pair programming and code inspections seem to work about equally well for finding defects; a good reminder that this year's popular techniques aren't necessarily better than the tried-and-true.

Plenty of Advanced, Too
The book doesn't stop with the basics, though. If you're an intermediate or advanced developer, you still have things to learn here. Consider, for example, the two-chapter discussion of code-tuning strategies and techniques. Instead of diving right into low-level tuning ideas, or even an overview of code tuning, McConnell starts by discussing performance requirements in general. He brings out the fact that many times performance is overstated as a requirement. Even when it's really required, code is only one way to improve performance — often, just spending a few thousand dollars more on hardware is a simpler and cheaper solution.

But assuming you've looked at the big picture and decided that your code really does need to be tuned, this book will go right down into the trenches with you. It introduces (or reminds you of, depending on your background and experience) the Pareto Principle (that 20 percent of the code accounts for 80 percent of the time spent). The message is clear; tuning without knowing where the bottlenecks are is just silly. Measure first, think, and then tune.

Finally, if you stick with the program, there is plenty of concrete advice here. You learn about common sources of inefficiency, about compiler optimization and about iterative approaches to tuning. McConnell gets right down into the best ways to write logic structures and loops in several different languages and discusses how to measure your own cases to confirm your approach to tuning.

Read With an Open Mind
Just about any developer will find things to disagree with here. McConnell, for example, doesn't think much of continuous integration if it means builds are done more often than daily. Yet despite his reliance on figures most everywhere else in the book, he backs this example up only anecdotally with a survey of his buddies at big IT shops. No doubt the XP folks are getting ready to e-mail him reams of studies proving the benefits of their practices. In other examples, you may actually like verbose comments at the start of procedures, or have a variable naming convention that clashes with what he lays out as best practices.

Developer Central Newsletter Want to read more of Mike's work? Sign up for the monthly Developer Central e-newsletter, including product reviews, links to web content, and more, at http://lists.101com.com/nl/main.asp?NL=adt.

All this is fine; after all, if you agreed with everything in the book already, what would be the point of reading it? You'll still likely benefit from considering the parts of the process that you've never thought about. Take what you like from the book (which is most likely going to be a whole lot of it) and leave the rest on the cutting-room floor.

More than a Fresh Coat of Paint
If you've read the first edition, you'll be wondering whether the second edition is substantially different. Even though the author doesn't provide any introduction in the book to tell you this, the answer is "yes." McConnell introduces plenty of new research to his array of facts and figures. Some of the latest trends, like agile programming, make it in — though they don't dominate the book.

One sweeping change is a focus on object-oriented programming, which was not as clearly a winning strategy a decade ago as it is today. Along with this focus comes a rewrite of most of the book's code samples to modern languages (C++, Java, and VB .NET). Finally, there's an associated Web site (http://www.cc2e.com) containing further info, printable checklists, and more.

As for me, I still recommend this book to every developer. It's just that now I'm recommending the new edition and guarding my final copy of the first edition more carefully than ever.

Have you read a great programming book lately? Think I ought to cover it? You can get hold of me at [email protected]. I'll use the most interesting comments in a future issue of Developer Central.