By Steve McConnell, Chief Software Engineer, Construx Software Builders
How do you convince people to pay attention to their software
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:
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
- Conducting systematic technical reviews of all requirements, designs and
- Developing a systematic quality assurance plan in the very early stages
of the project that includes a test plan, review plan and defect tracking
- 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
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
- 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
- Because the project is having schedule trouble, developers are asked to
re-estimate 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.
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
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.
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.
This article was adapted from the author’s book, “Software Project Survival
Guide” (Microsoft Press, 1998). Reprinted with permission of the author.
Steve McConnell is CEO and Chief Software Engineer at Construx
Software where he writes books and articles, teaches classes and oversees
Construx’s software engineering practices. He has worked in the desktop software
industry since 1984 and has expertise in rapid development methodologies,
project estimation, software construction practices, performance tuning, system
integration, and third-party contract management. Steve has authored many books
–“Code Complete” and “Rapid Development,” both winners of Software Development
magazine's Jolt award for outstanding software development books. He also served
as Editor in Chief of IEEE Software from 1998 – 2002 and is a member of IEEE
Computer Society and ACM. Contact him at