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.
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
(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
available. That makes this an appropriate time to revisit
this title, and explain why I still recommend it to every developer I
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.
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.
| 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,
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 MikeG1@larkfarm.com.
I'll use the most interesting comments in a future issue of Developer