Five Easy Steps Toward Disaster

Although there are an unlimited number of ways you can foul up a programming project, here are a few particularly popular ones:

1: Pile on the Features

The easiest way to ruin a program is to add a whole series of features to it without enough time to integrate them properly. Under heavy time pressure, the natural tendency is to glue the new functionality anywhere you can, without thinking about how you're affecting the core design of the program.

After you have done this several times, the resulting program becomes a diffuse and unwieldy collection of modules, and nobody understands how they interact. Making any further changes requires an act of faith.

2: Target Heterogeneous Environments

It is hard to support the kind of hardware and software variations that are common in the PC industry. Because no organization can try every possible system configuration, programs refuse to install, run poorly or not at all, and interact unpredictably with other applications.

Here are two ways to make the problems worse. First, take undocumented shortcuts that probably will not be supported in future releases. Second, don't bother to follow the standard interface guidelines of the system. This ensures that users and other programmers are confused.

3: Test Inadequately

Because formal proofs won't eliminate bugs anytime soon, careful testing is the only way to be sure that a program works correctly. Consequently, disaster aficionados should delay systematic product testing until coding is almost finished. At that point, programmers can't easily undo faulty design decisions, and it's hard to isolate bugs.

4: Document Poorly

Most programmers don't like to write documentation. This is a real aid to disaster because good notes on the basic internal systems design are valuable when it's time to update. Reliability will result if development team leaders make sure programmers write the documentation and keep it up to date.

If the documents do go out of date, whatever you do, don't schedule extra time to clean them up at the end of the project. If you're a disaster seeker, you can take comfort in the fact that memories will fade quickly when programmers move on to a new task.

5: When In Doubt, Vacillate

The team leaders should avoid clearly defined project specifications and change specifications whenever pressure to do so strikes.