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.

• By Mike Gunderloy
• April 01, 2003

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 years ago.

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 (http://www.spmn.com/products_software.html).

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.