IEEE Computer, May 1998

"The Power of Process"

---

How do you convince people to pay attention to their software development processes?

The word "process" is viewed as a four-letter word by some people in the software development community. These people see "Software Processes" as rigid, restrictive, and inefficient. They hold that the best way to run a project is to hire the best people you can, give them all the resources they ask for, and turn them loose to do what they do best. According to this viewpoint, projects that run without any attention to process can run extremely efficiently. People who hold this viewpoint imagine a work breakdown over the course of a project like the one shown in Figure 1:

Figure 1.

People who hold this view acknowledge that some amount of "thrashing," or unproductive work, will take place. Developers will make mistakes, they agree, but they will be able to correct them quickly and efficiently—certainly at less overall cost than the cost of "Process."

The phrase "software processes" can mean a lot of different things. Here are some examples of what I mean by "software processes":

• Committing all requirements to writing.
• Using a systematic procedure to control additions and changes to the product’s requirements.
• Conducting systematic technical reviews of all requirements, designs, and source code.
• Developing a systematic quality assurance plan in the very early stages of the project that includes a test plan, review plan, and defect tracking plan.
• Creating an implementation plan that defines the order in which the product’s functional components will be developed and integrated.
• Using automated source code control.

According to the view expressed by Figure 1, adding processes like these, as is shown in Figure 2, is pure overhead and simply takes time away from productive work.

Figure 2.

This point of view has intuitive appeal. At the beginning of a project (shown by the darker shaded areas), a focus on process certainly does take time away from productive work. If that trend were to continue throughout a project (shown by the lighter shaded areas), it wouldn’t make sense to spend much time on process.

Experienced View of Process

Based on software industry experience, however, for medium and large projects the trend shown in Figure 2 does not continue throughout the project. Projects that don’t pay attention to establishing effective processes early are forced to slap them together late, when slapping them together takes more time and does less good. Here are some examples:

• In the middle of the project, team members agree informally to implement a wide variety of changes that are proposed to them directly by their manager or customer. They don’t begin controlling changes systematically until late in the project. By that time, the scope of the product has expanded by 25 to 50 percent or more, and the budget and schedule have expanded accordingly.
• Projects that don’t set up processes to eliminate defects in early stages fall into seemingly interminable test-debug-reimplement-retest cycles. So many defects are discovered that, by the end of the project, the "change control board" or "feature team" may meet as often as every day to prioritize defect corrections. Because of the vast number of defects, the software has to be released with many known (albeit low priority) defects. In the worst case, the software might never reach a level of quality good enough to be released.
• Alternatively, major defects discovered late in the project can cause the software to be redesigned and rewritten during testing. Since no one planned to rewrite the software during testing, the project deviates so far from its plans that it essentially runs without any planning or control.
• Defect tracking isn’t set up until late in the project. Some reported defects go unfixed simply because they are forgotten, and the product is released with known defects that could have been fixed easily.
• Components developed by different developers are not integrated with each other until the end of the project. By the time the components are integrated, the interfaces between components have gotten out of synch, and much work must be done to bring them back into alignment.
• Source code revision control isn’t established until late in the project, after developers have begun to lose work by accidentally overwriting the master copies of their own or each other’s source code files.
• Because the project is having schedule trouble, developers are asked to reestimate their remaining work as often as once a week or more, taking time away from their development work.

When a project has paid too little early attention to the processes it will use, by the end of a project developers feel they are spending all of their time in meetings and correcting defects and little or no time extending the software. They know the project is thrashing. When developers see they are not meeting their deadlines, their survival impulses kick in and they retreat to "solo development mode"—focusing exclusively on their personal deadlines. They withdraw from interactions with managers, customers, testers, technical writers, and the rest of the development team. Project coordination unravels.

Far from the steady level of productive work suggested by Figure 1, my observation is that the medium or large project conducted without much attention to development processes typically experiences the pattern shown in Figure 3.

Figure 3.

In this pattern, projects experience a steady increase in thrashing over the course of a project. By the middle of the project, the team realizes that it is spending a lot of time thrashing and that some process would be beneficial. But by then much of the damage has been done. The project team tries to increase the effectiveness of their process, but their efforts hold the level of thrashing steady, at best. In some cases, the late attempt to improve the project’s processes actually makes the thrashing worse.

The lucky projects release their products while they are still eking out a small amount of productive work. The unlucky products can’t complete their products before reaching a point at which 100 percent of their time is spent on process and thrashing. After spending several weeks or months in this condition, these projects are typically cancelled when management or the customer realizes that they are no longer moving forward. If you think that attention to process is needless overhead, consider that a canceled project has an overhead of 100 percent.

Process to the Rescue

Fortunately, an attention to software development process provides an alternative to this dismal scenario. When effective processes are used, the project profile looks like the one shown in Figure 4.

Figure 4.

During the first few weeks of the project, the process-oriented team will seem less productive than the process-phobic team because the level of thrashing will be the same on both projects and the process-oriented team will be spending a significant amount of its time on processes. But an investment made in process at the beginning of the project produces large returns later in the project.

By the middle of the project, the team that focused on process early will have reduced the level of thrashing compared to the beginning of the project, and will have streamlined its processes. At that point, the process-phobic team will be just beginning to realize that thrashing is a significant problem and just beginning to institute some processes of its own.

By the end of the project, the process-oriented team will be operating at a high-speed hum, with little thrashing, and performing its processes with little conscious effort. It will tolerate a small amount of thrashing because eliminating the last bit of thrashing would cost more in overhead than would be saved. When all is said and done, the overall effort on the project will be considerably lower than the effort of the process-phobic team.

Organizations that have explicitly focused on improving their development processes have, over several years, cut their times-to-market by about one-half and have reduced their costs and defects by factors of 3 to 10.

• Over a 5 year period, Lockheed cut its development costs by 75 percent, reduced its time to market by 40 percent, and reduced its defects by 90 percent (Alfred M. Pietrasanta, "A Strategy for Software Process Improvement," Ninth Annual Pacific Northwest Software Quality Conference, October 7-8, 1991, Oregon Convention Center, Portland, OR).

• Over a 6.5 year period, Raytheon tripled its productivity and realized a return on investment (ROI) in process improvement of almost 8 to 1 (Raytheon Electronic Systems, Advertisement, IEEE Software, September 1995, back cover, Hossein Saiedian and Scott Hamilton, "Case Studies of Hughes and Raytheon’s CMM Efforts," IEEE Computer, January 1995, pp. 20-21).

• Bull HN realized an ROI of 4 to 1 after four years of software process improvement, and Schlumberger realized an ROI of almost 9 to 1 after 3.5 years of software process improvement (James Herbsleb, et al, Benefits of CMM Based Software Process Improvement: Initial Results, Pittsburgh: Software Engineering Institute, Document CMU/SEI-94-TR-13, August 1994).

• NASA’s Software Engineering Laboratory cut its average cost per mission by 50 percent and its defect rate by 75 percent over an 8 year period, while dramatically increasing the complexity of software used on each mission (Victor Basili et al, "SEL’s Software Process Improvement Program," IEEE Software, November 1995, pp. 887).

Similar results have been reported at Hughes, Loral, Motorola, Xerox and other companies that have focused on systematically improving their software processes (Hossein Saiedian and Scott Hamilton, "Case Studies of Hughes and Raytheon’s CMM Efforts," IEEE Computer, January 1995, pp. 20-21; Myers, Ware, "Good Software Practices Pay Off—Or Do They?" IEEE Software, March 1992, pp. 96-97; Herbsleb, James, et al, "Software Process Improvement: State of the Payoff," American Programmer, September 1994, pp. 2-12.).

Here’s the best news. The average cost of these improvements was only about 2 percent of total development costs—typically about $1,500 per developer per year (Herbsleb, James, et al, Benefits of CMM Based Software Process Improvement: Initial Results, Pittsburgh: Software Engineering Institute, Document CMU/SEI-94-TR-13, August 1994).

Process vs. Creativity and Morale

One of the common objections to putting systematic processes in place is that they will limit programmers’ creativity. Programmers do indeed have a high need to be creative. Managers and project sponsors also have a need for projects to be predictable, to provide progress visibility, and to meet schedule, budget, and other targets.

The criticism that systematic processes limit developers’ creativity is based on the mistaken idea that there is some contradiction between developers’ creativity and the satisfaction of management objectives. It is certainly possible to create an oppressive environment in which programmer creativity and management goals are placed at odds, and many companies have done that, but it is just as possible to set up an environment in which those goals are in harmony and can be achieved simultaneously.

Companies that have focused on process have found that effective processes support creativity and morale. In a survey of about 50 companies, only 20 percent of the people in the least process-oriented companies rated their staff morale as "good" or "excellent" (James Herbsleb, et al, "Software Quality and the Capability Maturity Model," Communications of the ACM, June 1997, pp. 30-40.) The responses listed were consistent across managers, developers responsible for process improvement, and general senior technical staff members. In organizations that paid more attention to their software processes, the proportion of people who rated their staff morale as "good" or "excellent" jumped to 50 percent. And, in the most process-sophisticated organizations, 60 percent of the people rated their morale as "good" or "excellent."

Programmers feel best when they’re productive. Programmers dislike weak leadership that provides too little structure to prevent them from working at cross purposes and, in the end, causes them to spend more time fixing defects than creating new software. Good project leadership puts a focus on process that allows programmers to feel incredibly productive. Developers, their project, and their organization all reap the benefits.

About the Author

Steve McConnell is Chief Software Engineer at Construx Software Builders and Editor of IEEE Software’s "Best Practices" column. This article was adapted from his book, Software Project Survival Guide (Microsoft Press, 1998). Contact him at stevemcc@construx.com.