Software's Ten Essentials

best practices steve mcconnell

Software’s Ten Essentials

Prospecting for VIRTUALLY EVERY BACKPACKER, ROCK looks like working software, and it can have al- climber, and recreational hiker in the Pacific most the same effect. programmer’s Northwest is familiar with the Seattle No experienced hiker would think of going gold. Mountaineers’ list of the “Ten Essentials”: extra on a long hike without sufficient food, water, clothing, extra food, sunglasses, knife, fire starter, and clothing. On a software project, a realistic first aid kit, waterproof matches, flashlight, map, schedule provides the essential planning founda- and compass. In fact, the list is fairly universal. The Ten Essentials are the result of years of Setting “I want it all” hard-won experience. They are intended to help mountaineers avoid getting into trouble in the priorities is first place, and, if that doesn’t work, to minimize the damage. No experienced mountaineer would like setting go into the mountains without the Ten Essentials. no priorities at all. Experienced software developers have also ac- cumulated years of hard-won experience. Our tion for adequate staffing, adequate quality as- software adventures often contain more uncharted surance activities, and in general the appropri- paths and dangerous territory than a simple hike ate level of formality in the project’s software in the woods, and so I propose a list of Ten processes. Every fall we hear of hikers trapped Essentials for software projects. in the woods by an unexpected snowstorm. Every spring we hear about a software product MAP, COMPASS, AND SUPPLIES. A product specification that was supposed to ship on January 1 but is a software project’s compass. Without one, you doesn’t actually ship until many months later. can perform the work of Hercules and still not Basing a software project on an unrealistic produce a viable product, because your efforts schedule and the insufficient staffing and tech- haven’t been aimed in any particular direction. nical planning that result from it is tantamount Without good direction, any individual’s work to heading into the woods in November without can go astray, and people end up operating at a warm jacket. cross-purposes. With today’s highly interactive systems it is PLANNING AHEAD. If a hiker gets into trouble, it’s becoming increasingly difficult to capture the useful to know that a person can go for days essence of a product specification without con- without food but not without water. A successful structing a detailed user-interface prototype. Static software project establishes explicit priorities, so if paper documentation often cannot adequately it gets into trouble management knows which describe a product’s intended look and feel. If features are essential and which can be jetti- the product specification is the compass, the soned. Explicit priorities help to avoid the prob- user interface prototype is the map that points lem of wanting all possible features with the best out the hills and valleys, graded trails, and por- quality in the shortest time with the least effort. tions of the software outing that will require Setting “I want it all” priorities is equivalent to Editor: special skills. setting no priorities at all. They provide no Steve McConnell A beneficial side effect of user interface proto- guidance when the project needs to make tough typing is that it can be an effective way of light- choices. Explicit priorities make the tough Construx Software Builders ing a fire under both the customer and the devel- choices easier. PO Box 6922 opment team. Visibly working software is good A common theme running through the Ten Bellevue, WA 98008 for customer and developer morale. A user inter- Essentials is that of hoping for the best but [email protected] face prototype isn’t working software, but it preparing for the worst. You wouldn’t go hiking

if you expected to break your leg, and SOFTWARE’S TEN ESSENTIALS you wouldn’t start a software project if you expected it to run 300 percent over 1. A product specification budget. In spite of your best hopes, how- 2. A detailed user interface prototype ever, you’d be foolish to go hiking with- 3. A realistic schedule out adequately preparing for the risks in- 4. Explicit priorities herent in the activity. Active risk management is also a key component of success- 5. Active risk management ful software projects. As Tom Gilb says, 6. A quality assurance plan if you do not actively attack project risks, 7. Detailed activity lists they will actively attack you. 8. Software configuration management A quality assurance plan is the software project’s first-aid kit. The top priority in 9. Software architecture first aid is to avoid doing anything that 10. An integration plan 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 developers inadvertently overwriting grating software components that were practical equivalent of leaving the first- each other’s work. Source code control not designed with integration in mind. aid kit in the car. By the time problems is typically combined with an off-site An explicit integration plan is therefore become too obvious to ignore, much of backup plan so you’re not left in the the last of the Ten Essentials. With a the damage has been done: Developers cold if the server containing the master good integration plan such as the Daily have inserted defects into the product sources crashes. Build process (see this column in IEEE and not corrected them during require- The most successful projects also put Software, July 1996), you can almost ments and design activities. All you can designs, requirements, and project plan- forget that integration tends to be a do at that point is correct the defects, at ning materials under configuration man- troublesome issue. Without an integra- great cost, during construction and sys- agement. When this is done, a change in tion plan, you can enter an extended in- tem testing. A good quality assurance the schedule or budget requires explicit tegration/test/bug-fix cycle that ex- plan will aim to detect defects early, approval and notification of the con- poses so many defects that it can kill close to the point of insertion, and not cerned parties. This helps to keep sched- the project. allow defects to infect work later in the ule- and budget-related decisions visible project. and prevents hundreds of small changes OTHER ESSENTIALS. Several organizations For longer trips, hikers have to file an from quietly accumulating into large have published similar lists of software itinerary. If the hikers file a three-day schedule and budget overruns. project essentials. The Software Project itinerary but then don’t return within Sometimes you’ll see a hiker with a Manager’s Network publishes a “Project three or four days, the Forest Service 20-year-old backpack, patched together Breathalyzer,” a 10-question test de- sends out a search party. Successful soft- with so much duct tape and twine that signed to determine whether a project ware projects use detailed activity lists, you can’t make out the original pack. should be “on the road.” The test is comprised of tasks that last a few days That’s what software systems developed available on the Internet from http:// each and that are considered to be either without an explicit focus on software ar- www.spmn.com. The Standish Group done or not done—not “90 percent chitecture look like. Internally, software published a report titled “Charting the done.” Comparing the list of completed architecture promotes consistent design Seas of Information Technology,” activities to the list of planned activities and implementation approaches, which which includes a list of the top 10 suc- indicates whether a project is on time or in turn facilitate future corrections and cess factors for MIS projects. The key needs to be rescued. extensions. Externally, the most visible process areas required to advance from aspect of explicit software architecture is level 1 to level 2 of the Software MANAGING THE PIECES. Software configura- its support for consistent user interfaces. Engineering Institute’s Capability tion management won’t keep you warm Consistency is a generally desirable Maturity Model might also be consid- and dry, but it will keep you from suc- characteristic that you attain almost au- ered “essentials.” You can read about cumbing to some of the more dangerous tomatically when you have good archi- those in Capability Maturity Model for software project risks. At the most basic tecture and only with great difficulty Software, Version 1.1 by Mark C. Paulk level, software projects put source code when you don’t. and colleagues, which is downloadable under automated source code manage- One of the thorniest implementa- from the SEI’s Web site at http:// ment. This prevents problems such as tion problems is the problem of inte- www.sei.cmu.edu. ◆

I E E E SOFTWARE 143