Software's Ten Essentials
Steve McConnell, Construx Software
Virtually every backpacker, rock climber, and recreational hiker in the Pacific Northwest is familiar with the Seattle Mountaineers' list of the "Ten Essentials": extra clothing, extra food, sunglasses, knife, fire starter, first aid kit, waterproof matches, flashlight, map, and compass. In fact, the list is fairly universal.
The Ten Essentials are the result of years of hard-won experience. They are intended to help mountaineers avoid getting into trouble in the first place, and, if that doesn't work, to minimize the damage. No experienced mountaineer would go into the mountains without the Ten Essentials.
Experienced software developers have also accumulated years of hard-won experience. Our software adventures often contain more uncharted paths and dangerous territory than a simple hike in the woods, and so I propose a list of Ten Essentials for software projects.
Map, Compass, and Supplies
A product specification is a software project's compass. Without one, you can perform the work of Hercules and still not produce a viable product, because your efforts haven't been aimed in any particular direction. Without good direction, any individual's work can go astray, and people end up operating at cross-purposes.
With today's highly interactive systems it is becoming increasingly difficult to capture the essence of a product specification without constructing a detailed user-interface prototype. Static paper documentation often cannot adequately describe a product's intended look and feel. If the product specification is the compass, the user-interface prototype is the map that points out the hills and valleys, graded trails, and portions of the software outing that will require special skills.
A beneficial side effect of user interface prototyping is that it can be an effective way of lighting a fire under both the customer and the development team. Visibly working software is good for customer and developer morale. A user interface prototype isn't working software, but it looks like working software, and it can have almost the same effect.
No experienced hiker would think of going on a long hike without sufficient food, water, and clothing. On a software project, a realistic schedule provides the essential planning foundation for adequate staffing, adequate quality assurance activities, and in general the appropriate level of formality in the project's software processes. Every fall we hear of hikers trapped in the woods by an unexpected snowstorm. Every spring we hear about a software product that was supposed to ship on January 1 but doesn't actually ship until many months later. Basing a software project on an unrealistic schedule and the insufficient staffing and technical planning that result from it is tantamount to heading into the woods in November without a warm jacket.
Planning Ahead
If a hiker gets into trouble, it's useful to know that a person can go for days without food but not without water. A successful software project establishes explicit priorities, so if it gets into trouble management knows which features are essential and which can be jettisoned. Explicit priorities help to avoid the problem of wanting all possible features with the best quality in the shortest time with the least effort. Setting "I want it all" priorities is equivalent to setting no priorities at all. They provide no guidance when the project needs to make tough choices. Explicit priorities make the tough choices easier.
A common theme running through the Ten Essentials is that of hoping for the best but preparing for the worst. You wouldn't go hiking if you expected to break your leg, and you wouldn't start a software project if you expected it to run 300 percent over budget. In spite of your best hopes, however, you'd be foolish to go hiking without adequately preparing for the risks inherent in the activity. Active risk management is also a key component of successful software projects. As Tom Gilb says, if you do not actively attack project risks, they will actively attack you.
A quality assurance plan is the software project's first aid kit. The top priority in first aid is to avoid doing anything that will require you to use the kit. But even the most careful hikers sometimes get hurt, and thus a first aid kit is essential. Many software projects perform the practical equivalent of leaving the first aid kit in the car. By the time problems become too obvious to ignore, much of the damage has been done: Developers have inserted defects into the product and not corrected them during requirements and design activities. All you can do at that point is correct the defects, at great cost, during construction and system testing. A good quality assurance plan will aim to detect defects early, close to the point of insertion, and not allow defects to infect work later in the project.
For longer trips, hikers have to file an itinerary. If the hikers file a three-day itinerary but then don't return within three or four days, the Forest Service sends out a search party. Successful software projects use detailed activity lists, comprised of tasks that last a few days each and that are considered to be either done or not done—not "90 percent done." Comparing the list of completed activities to the list of planned activities indicates whether a project is on time or needs to be rescued.
Managing the Pieces
Software configuration management won't keep you warm and dry, but it will keep you from succumbing to some of the more dangerous software project risks. At the most basic level, software projects put source code under automated source code management. This prevents problems such as developers inadvertently overwriting each other's work. Source code control is typically combined with an off-site backup plan so you're not left in the cold if the server containing the master sources crashes.
The most successful projects also put designs, requirements, and project planning materials under configuration management. When this is done, a change in the schedule or budget requires explicit approval and notification of the concerned parties. This helps to keep schedule- and budget-related decisions visible and prevents hundreds of small changes from quietly accumulating into large schedule and budget overruns.
Sometimes you'll see a hiker with a 20-year-old backpack, patched together with so much duct tape and twine that you can't make out the original pack. That's what software systems developed without an explicit focus on software architecture look like. Internally, software architecture promotes consistent design and implementation approaches, which in turn facilitate future corrections and extensions. Externally, the most visible aspect of explicit software architecture is its support for consistent user interfaces. Consistency is a generally desirable characteristic that you attain almost automatically when you have good architecture and only with great difficulty when you don't.
One of the thorniest implementation problems is the problem of integrating software components that were not designed with integration in mind. An explicit integration plan is therefore the last of the Ten Essentials. With a good integration plan such as the Daily Build process (see this column in IEEE Software, July 1996), you can almost forget that integration tends to be a troublesome issue. Without an integration plan, you can enter an extended integration/test/bug-fix cycle that exposes so many defects that it can kill the project.
Other Essentials
Several organizations have published similar lists of software project essentials. The Software Project Manager's Network publishes a "Project Breathalyzer," a 10-question test designed to determine whether a project should be "on the road." The test is available on the Internet from http://www.spmn.com. The Standish Group published a report titled "Charting the Seas of Information Technology," which includes a list of the top 10 success factors for MIS projects. The key process areas required to advance from level 1 to level 2 of the Software Engineering Institute's Capability Maturity Model might also be considered "essentials." You can read about those in Capability Maturity Model for Software, Version 1.1 by Mark C. Paulk and colleagues, which is downloadable from the SEI's Web site.
Steve McConnell is CEO and chief engineer at Construx Software. Contact him at stevemcc@construx.com.
Software's Ten Essentials
- 1. A product specification
- 2. A detailed user interface prototype
- 3. A realistic schedule
- 4. Explicit priorities
- 5. Active risk management
- 6. A quality assurance plan
- 7. Detailed activity lists
- 8. Software configuration management
- 9. Software architecture
- 10. An integration plan
Reprinted from IEEE Software, vol. 14, no. 2, March/April 1997, pp. 144, 143.
