Beyond the Code
Trying to find out what went wrong with your last project? Pick up Steve McConnell's Software Project Survival Guide before you start the next one.
Since the early days of software development, our industry has been
the outstanding example of poor performance. Even today, few expect software
to be delivered on time and, when the products finally arrive, they often
have lots of defects.
—Watts S. Humphrey, "The
Changing World of Software"
Developers—like most everyone else—like to flex their muscles
and brag about their great work. Perhaps you've finally understood the
intricacies of code access security in .NET, or come up with a really
great use of the Table Data Gateway pattern in a distributed enterprise
application. It's a bit sobering, then, to realize that Watts Humphrey
isn't exaggerating when he calls us collectively "the outstanding example
of poor performance." Numbers vary, but serious studies seem to indicate
that between one-third and two-thirds of all the software projects underway
right now will be late and over budget. When you look at the big giant
projects run by huge consulting firms or large internal development teams,
about half get cancelled rather than delivered.
Imagine if baseball were run like software development. A third or more
of all games, from the little leagues on up, wouldn't happen as planned.
Perhaps the bus driver went to Tehachapi instead of Torrance, or the other
team showed up in football pads, or no one remembered to bring a ball.
And half the time you bought a ticket for a major league game, you'd file
into the ballpark along with 30,000 other fans only to watch
the teams leave the field after six innings because there's not enough
budget to pay the players to finish the job. Of course, those six innings
would take 14 hours to play, thanks to endless debates over the rules.
I think we'd all agree that was an intolerable situation. Why, then,
do we so blithely tolerate its equivalent in software? Apologists for
the industry may claim that it's just because software is hard stuff,
and that we don't know very well how to do it. But that point of view
get challenged by organizations like Carnegie-Mellon's Software Engineering
Institute or NASA's Software Engineering Lab. In fact, we do know quite
a bit about finishing software projects on time, on budget and with a
reasonable defect level. We just don't pay attention to what we know.
A Guide for the Busy Professional
The SEI, SEL and academic researchers have actually produced quite
a body of literature on what distinguishes successful software projects
from the rest. The problem is that if you're trying to learn how to use
System.EnterpriseServices to manage distributed transactions and object
pooling, you don't have time to dig into that literature. This tends to
be true of development managers as well as developers. Many project managers
have been promoted (some would debate whether that's the correct word)
from a coding position to a management one. It's understandable that the
challenging bugs in the code are of more interest to such managers than
the equally-challenging bugs in group dynamics and project estimation.
That's where Steve McConnell's book, Software
Project Survival Guide (Microsoft
Press, 1998) comes in. McConnell has been through the academic literature,
and he's been through the mill as a developer—and he's condensed
both sets of experience down to less than 300 readable pages. This is
the best book that I know of for you to pick up if you're trying to manage
(or contribute to) a software project and feel like you're slowly sinking.
(If you feel like you've already sunk, you might try Ed Yourdon's Death
March (Prentice-Hall, 1999) instead; that one is about your own
survival rather than the project's).
McConnell presents a series of strategies designed to help minimize risk
and keep projects on track. He emphasizes up-front planning, staged releases,
and careful tracking while a project is underway. Although software development
is filled with surprises, if you keep an eye on the process as it's underway
you can minimize their impact. Speaking of which, he emphasizes that "process"
is not a dirty word. While some of the more excessive proponents of agile
methods seem to go out of their way to be proud of having no process overhead,
McConnell points out how the right amount of process can actually increase
productive coding time by reducing the thrashing associated with bad decisions
and ill-conceived code explorations. (Which is not to say that either
he or I dismiss agile methods out of place; one just has to be aware of
when they're appropriate and when they're not.)
Making a List and Checking It Twice
One thing this book will give you is lists (as well as charts,
graphs, and other ways to keep track of what's going on). Each chapter
ends with a "Survival Check" section listing best practices that you should
keep in mind (things like "Developers review all designs and code before
the designs and code are considered 'done'") and pitfalls that can arise
in their use (like "No designs or code have failed their reviews, suggesting
that reviews are superficial"). While checklists alone won't make your
project succeed, they will help you remember all the things that you need
to keep in mind. If nothing else, you should run through the "Survival
Test" at the start of the book, which will give you a quick numerical
indication of whether your current project is already in trouble. You'll
also find the Survival Test, along with many other resources, on the book's
Web site (http://www.construx.com/survivalguide/),
which has been kept up to date even though the book was published five
One critical list that doesn't get used enough (at least, not in my experience)
is the Top 10 Risks List. We all know that there are threats to our project's
success: dependencies on code from an external group or an ISV that's
not quite ready yet, politics that could affect the funding, pressure
from the big boss to add just one more teeny-weeny feature. But how many
of us keep track of these risks, know which ones are increasing or decreasing,
and have a written mitigation plan for each one? Managing a software project
is more than just making sure warm bodies are assigned to each milestone.
You also have to be prepared to deal with the inevitable problems that
arise along the way. If you've thought about the potential problems in
advance, you'll be better prepared to deal with them. For a structured
approach to risk management, you might take a look at Risk Radar, a project
management utility from the military Software Program Managers Network
Milestones or Inch-Pebbles?
McConnell is a big proponent of miniature milestones (sometimes
called "inch-pebbles" or "microstones"). You don't know what you're doing
if you don't track your progress, and you can't track your progress without
having something to aim for. The more closely spaced the aiming points,
the better the chance that you can spot problems early. Daily milestones
is a good target to aim for. If one of your developers misses half a dozen
daily milestones in the course of a week, the chance is pretty good that
their overall schedule is wildly misestimated.
Some developers will hate, subvert or attempt to ignore the miniature
milestone process. They'll argue that time spent planning takes away from
time spent coding, and that they know what needs to be done so they'll
just get to it. McConnell gives this sort of argument short shrift:
"Expect some initial resistance, but beware of the developer who
resists miniature milestones at all costs. Such a developer is literally
out of control—you'll never have a clear sense of what the developer
is working on or the status of the work. That developer's attempt to
avoid accountability at all costs gives you the best hint you're likely
to get about that developer's contribution to the project."
Go Forth and Manage
Whatever your position in the development world, you can probably
learn from this book. If you're a developer, reading and reflecting about
the best practices here will help you identify ways in which your own
work could be more efficient. If you're a manager trying to run a development
team, you can find enough accumulated wisdom to substantially increase
your chance of success. And we all like success— it's almost as good
for muscle-flexing as figuring out tricky algorithms.