From the Editor
IEEE Software, November/December 2001
Quantifying Soft Factors
The role that soft, human-oriented factors play in software effectiveness
sometimes gets lost in discussions of best practices, process models, and
other more complex topics.
Limited Importance of Process Maturity
One of the articles in this issue, Brad Clark’s "Quantifying the Effect of
Process Improvement," has a perhaps startling message for more
process-oriented readers: a one-CMM-level improvement by itself accounts for
only an 11% increase in productivity.1
In comparing medium-size projects (100,000 lines of code), the one with the
worst process will require 1.43 times as much effort as the one with the
best process, all other things being equal. In other words, the maximum
influence of process maturity on a project’s productivity is 1.43.
What Clark doesn’t emphasize is that for a program of 100,000 lines of
code, several human-oriented factors influence productivity more than
process does. According to the regression studies performed to calibrate the
Cocomo II estimation model, analyst experience (AEXP in Cocomo II) exerts an
influence of 1.51. Communications factors (SITE, which refers to colocation
of personnel and communication support such as e-mail and networks) exert an
influence of 1.52. Personnel continuity (PCON) has an influence of 1.59.
Programmer capability (PCAP) has an influence of 1.77, and the capability of
the requirements analysts (ACAP) has an influence of 2.00. Language and tool
experience (LTEX) exert the same influence as process maturity (1.43), and,
trailing only slightly, programmer experience (PEXP) exerts an influence of
The effect of process maturity varies with project size; it has less
influence in small projects. For a project of 10,000 lines of code, process
maturity affects productivity less than any of the other factors mentioned.
The seniority-oriented factors alone (AEXP, LTEX, PEXP) exert an influence
of 3.02. The seven personnel-oriented factors collectively (ACAP, AEXP,
LTEX, PCAP, PCON, PEXP, and SITE) exert a staggering influence range of
25.8! This simple fact accounts for much of the reason that
non-process-oriented organizations such as Microsoft, Amazon.com, and other
entrepreneurial powerhouses can experience industry-leading productivity
while seemingly shortchanging process.
One soft factor that the Cocomo II analysis doesn’t quantify is the effect
of the office environment. Tom DeMarco and Timothy Lister sponsored a
now-famous programming competition in which 166 developers competed on the
basis of quality and speed.2
The competitors provided information on the characteristics of their physical
work environments, and it turned out that the developers who performed in
the top 25% had bigger, quieter, more private offices and fewer
interruptions from people and phone calls than the other 75%. The
differences in physical space weren’t especially dramatic. The top 25% of
performers had an average of 78 square feet of dedicated floor space; the
bottom 25% had 46 square feet.
The differences in productivity were more dramatic. Developers in the top
quartile had productivity 2.6 times better than developers in the bottom
quartile. In Cocomo II terms, the influence of office environment is 2.6,
which is significantly greater than that of process maturity.
Motivation is usually thought to be the greatest influence on how well
people perform, and most productivity studies agree.3
Whatever else its critics might say about Microsoft, everyone agrees that
it has succeeded in motivating its developers to an extraordinary degree.
Stories of 12-, 14-, even 18-hour days are common, as are stories of people
who live in their offices for weeks at a time. I know of one developer who
had a Murphy bed custom-made to fit his office. Locally, Microsoft is known
as "The Velvet Sweatshop," which suggests that, if anything, the company
might be doing too good a job of motivating its employees.
Microsoft’s approach to achieving this high level of motivation is simple.
It focuses explicitly on morale. Each work group has a morale budget it can
use for anything it wants. Some groups buy movie-theater style popcorn
poppers, some go skiing or bowling or have a cookout, and some make
T-shirts. Some groups rent a whole movie theater for a private screening of
their favorite movie.
Microsoft also uses nonmonetary rewards extensively. I spent a year at
Microsoft working on Windows 3.1. During that time, I received three team
T-shirts, a team rugby shirt, a team beach towel, and a team mouse pad. I
also took part in a team train ride, a nice dinner on the local "Dinner
Train," and another dinner at a nice restaurant. If I had been an employee,
I also would have received a few more shirts, a Microsoft watch, a plaque
for participating in the project, and a big Lucite "Ship-It" award for
shipping the product. This stuff’s total value is probably only $300 or
$400, but its psychological value is much greater.
Microsoft doesn’t ignore developers’ personal lives, either. During the
time I was there, the developer whose office was next to mine had his
10-year-old daughter come by every day after school. She did her homework
quietly in his office while he worked. No one at the company even raised an
In addition to providing explicit support for morale, Microsoft gladly
trades other factors to keep morale high, sometimes in ways that would make
other companies shudder. I’ve seen them trade methodological purity,
programming discipline, control over the product specification, control over
the schedule, management visibility—almost anything to benefit morale.
Regardless of the other effects, the motivational efficacy of this approach
speaks for itself.
Falling in line with Cocomo’s emphasis on staff seniority, many leading
organizations recognize the importance of senior staff. Many years ago,
Microsoft’s director of development pointed out to me that he had identified
senior personnel as a critical success factor. He said that one of the keys
to success of a product such as Microsoft Excel was to have at least two
senior staff members continue over from the product’s previous release.
In a study of runaway projects in the UK, managers identified "insufficient
senior staff" as a contributing cause of difficulties in approximately 40%
of the projects that significantly overran their schedules or budgets.4
Even organizations that focus strongly on software processes recognize the
important role of human factors. The NASA Software Engineering Laboratory
was the first organization to win the IEEE Computer Society’s award for
software process achievement. In their "Recommended Approach to Software
Development, Revision 3," one of their top nine recommendations is "Do start
the project with a small, senior staff."5
The Bottom Line
It turns out that trading process sophistication for staff continuity,
business domain experience, private offices, and other human-oriented
factors is a sound economic tradeoff. Of course, the best organizations
achieve high motivation and process sophistication at the same time,6
and that is the key challenge for any leading software organization.
1. B. Clark, "Quantifying the Effect of Process Improvement," IEEE
Software, Vol. XX, No. 6, Nov,–Dec. 2000.
2. T. DeMarco and T. Lister, "Programmer Performance and the Effects of the
Workplace," Proc. 8th Int’l Conf. Software Eng., 1985, pp. 268–272.
3. B.W. Boehm, Software Engineering Economics, Prentice-Hall,
Englewood Cliffs, N.J., 1981.
4. A. Cole, "Runaway Projects—Cause and Effects," Software World,
Vol. 26, No. 3, 1995, pp. 3–5.
5. "Recommended Approach to Software Development, Revision 3," Doc. No.
SEL-81-305, NASA Goddard Space Flight Center, Greenbelt, Md., 1992.
6. S. Ahuja, "Laying the Groundwork for Success" (Interview), IEEE
Software, Vol. XX, No. 6, Nov.–Dec. 1999, pp. 72–75.
Editor: Steve McConnell, Construx Software, 14715 Bel-Red
Road, #100, Bellevue, WA 98007.
E-mail: firstname.lastname@example.org -