How to Survive the Software Swamp

Sometimes, a software project is like a swamp. You're up to your neck in alligators (mission failures) while mosquitoes (bugs) swarm around your head. You think, "If only I could build a platform above the alligators and mosquitoes, I could really produce great work!"

Then along comes a guy with a ladder. He says, "Stick this into the swamp bottom and climb up on it—you'll get away from all that!" For a while, this works, but then great winds (project stresses) blow over the ladder and all of your work sinks to the bottom.

For years, I’ve been a guy with a ladder. I've told project teams that the way to solve their problems is to be more rigorous in requirements specification, design, inspection, and testing. I've taught people how to use the Cleanroom approach to development (see sidebar), including formal specifications and statistical testing.

Projects using these techniques have usually been successful, but some projects have abandoned Cleanroom's rigorous defect-prevention procedures after a time. Why? Most had not adopted basic software engineering practices to fall back on when personnel or deadlines changed. From what I have seen, the most successful projects (and organizations) are those that have broadly adopted a set of basic software engineering practices. These projects then use more advanced or specialized techniques where those methods are truly appropriate.

The foundation of basic practices provides a platform on which to place your ladder. And, if the ladder topples, you don't fall back in among the gators.

If you don't develop broad, grass-roots acceptance of the fundamentals, three things can go wrong when you introduce advanced techniques. First, there will be plenty of engineers either actively trying to subvert the effort, or merely trying to "wait it out" in hopes it will go away. Second, if you don't choose the right targets for software process improvement, you will waste valuable resources fixing the wrong problems. Finally, if you don't plan for having several processes in use at once, your careful efforts will result in chaos. Here are some ways to avoid each of these mistakes.

Develop Broad Consensus on Basic Practices
Before you look at advanced techniques, make sure everyone on the project has agreed on a set of good software engineering practices. These practices need to be tailored for your project, and simple enough that they will be universally accepted. The foundation must be broad to survive project stresses like turnover, reorganizations, requirements changes, and "crunch mode." You must make these practices part of the fabric of the organization so that people no longer question the practices' worth or try to eliminate them as part of "cost-cutting" measures. You should define foundation practices in all of the following areas:

1. Requirements management
2. Software project planning
3. Peer review
4. Quality assurance
5. Software configuration management
6. Metrics
7. Defect Prevention

Although "Defect Prevention" is an advanced practice of the Software Engineering Institute's Software Capability Maturity Model (SWCMM), you could probably get everyone to at least agree to informal discussion of significant software bugs. Start by using part of the weekly staff meeting to discuss any bug that took more than two hours to fix. Talk about how to prevent that bug or similar ones. You’ll see programmers looking at their code after the meeting, to find similar problems before they are seen in testing.

Use Risk Analysis to Select New Practices
After you have established (and documented) a baseline of universal agreement, you can look at areas of process improvement based on the project risks you see on the horizon. Then you can prioritize the risks, addressing those that are most significant—rather than