From the Editor
IEEE Software, July/August 2001
Common Sense
"I like your columns, but they’re really all just common sense," a client
told me. He didn’t have a software background, and my columns were his first
introduction to systematic ways of understanding software projects. To my
chagrin, the net effect of a well-written column appeared to be that he
thought software engineering was trivial!
The idea that good software engineering "is all just common sense" is one
of my pet peeves. If good software engineering were really all just common
sense, we should expect to see projects routinely meet their schedule and
budget targets and delight their end users. I shouldn’t receive emails every
week that describe projects that seem sensible initially, but that end up
failing dramatically.
A Catalog of Proverbs
How much does common sense tell us about software engineering? Let’s look
at several common proverbs and see how well they apply to software.
Let sleeping dogs lie. This bit of common sense implies that issues
that aren’t currently causing problems for a software project should be left
alone. Wait until the issues become problems, and then worry about them.
Don’t waste time worrying about them prematurely.
How true is this common sense when applied to software projects? A key
success factor in software project management is active risk management, in
which we proactively search out sleeping dogs, poke them and prod them until
they wake up, and then deliberately try to move them out of the project’s
way. Failure to actively manage risks is one of the biggest contributors to
software project failure.1 Conversely, many authorities cite
active risk management as one of the most significant contributors to
software project success,2 and the Software Project Manager’s
Network lists risk management first in its list of 16 practices critical for
software.3
This common sense turns out to be 180 degrees wrong. The American sage
Benjamin Franklin assessed the software situation better 200 years ago when
he said, "A little neglect may breed great mischief."
Two heads are better than one. This is an interesting adage if only
because it competes with another aphorism, "Too many cooks spoil the broth."
Which is right? In the software engineering classic The Mythical
Man-Month, Fred Brooks argues that one of the most difficult challenges
on large software projects is maintaining the conceptual integrity of a
software design. Brooks proposes a Surgical Team/Chief Programmer Team
programming model, one of the main benefits of which is that most of the
design decisions are made by one mind—the mind of the chief programmer. In
this context, two heads may not be better than one; too many cooks may
indeed spoil the broth.
On the other hand, one of the most effective techniques in software
engineering is formal inspections, which are based on the idea that a
reviewer can detect problems that the original author of a work product will
overlook. Inspections are one of the techniques that has indisputably proven
their worth in practice,5 so it would seem that these two
common-sense sayings are both right, and they are both wrong—depending on
the context.
An ounce of prevention is worth a pound of cure. The average projects
spends 40-80 percent of its total effort fixing defects. Software industry
research has generally found that upstream defect-prevention work pays big
dividends in downstream rework avoidance. As I described in my column in the
previous issue of IEEE Software, however, there are limits to how
much prevention any project can stand. One contribution of the agile
programming movement is to cast a critical eye toward prevention and ensure
that projects do not spend more on prevention than they would need to spend
on cure. On balance, I think this common sense maxim does apply to software,
but we need to be careful not to overextend it, i.e., "Moderation in all
things."
He who hesitates is lost. Software projects occasionally become mired
in analysis paralysis—debating endless design alternatives, gold-plating
project plans, and so on. The point of this maxim seems to be to instill a
bias toward action. Regrettably, in software, the common tendency is not
toward analysis paralysis but toward underplanning.1
A project’s success or failure is often determined within the first 10-20
percent of the project,6
and counter to the common sense, hesitating (or planning) is a sign of a
healthy, well-run project. In this case the common sense is unclear because
we again have dueling maxims. For software, I prefer "look before you leap,"
or, drawing on Benjamin Franklin again, "failure to prepare is preparing to
fail."
Spare the rod; spoil the child. This saying refers to disciplining
children and is based on the belief that strictly enforcing rules will
produce well-behaved children; leniency will produce spoiled, disobedient
children. In software, we commonly see managers, customers, and marketing
departments who seem to take this proverb to heart. They believe that
coercing their development teams into working longer hours will produce the
software in a shorter time frame. The high-brow management version of this
old chestnut is Parkinson’s law, "work expands to fill available time,"
which I see used as justification for numerous coercive and manipulative
management practices.
Here again, the common sense guideline is diametrically opposed to the
software reality. Software design and construction are highly contemplative,
internal activities. A developer must be highly motivated to be able to do
software development work at all. One of the most basic results of
motivation research is that when a person tries to apply external motivation
to someone who is already highly internally motivated, internal motivation
decreases. Thus the net effect of "using the rod" is a reduction in internal
motivation and the effect on productivity is a net loss.4
Based on these examples, it appears that common sense is not a good basis
for practicing software engineering. Someone who believes that software
development is all common sense will likely run afoul of another pearl from
Benjamin Franklin: "Life’s tragedy is that we get old too soon and wise too
late."
Making It Look Easy
With all these counterexamples, why do intelligent people continue to think
good software engineering practices are just common sense?
After pondering this question for the past 10 years, I have concluded that
the phenomenon is related to the notion of conditional probability.
Conditional probability is the branch of probability that deals with how the
probability of future events is related to the occurrence of past events. If
you flip a coin, what are the odds of it coming up heads 10 times in a row?
The odds are 1 in 2 raised to 10th power, or 1 in 1024. But what
if the coin has already been flipped 9 times and come up heads each time?
What are the odds that the coin will come up heads 10 times in a row? The
only remaining random event is the last coin toss. The coin will either come
up heads, making 10 heads in a row, or tails, making 9 heads in a row
followed by one tail. Thus, the conditional probability of a coin coming up
heads 10 times in a row—if it’s already come up heads 9 times in a row—is 1
in 2, or 50 percent.
The claim that software engineering is all "common sense" is related to the
idea of conditional probability. Once someone has explained the concepts
clearly, it all seems like common sense because the newcomers don’t have to
explore all the answers that sounded plausible but that turned out to be
wrong. They didn’t see the 500 series of coin tosses in which we got a tails
on the first, second, or third toss. They’re only seeing the series from the
vantage point of already having 9 heads with one to go. They think that
software engineering is common sense because they haven’t banged their heads
against the wrong answers enough times to know just how many wrong answers
there are.
The fact that people think any part of software engineering is
commonsensical can be interpreted as a sign that the field is maturing. A
few effective practices are now being described so clearly that they appear
to be obvious. When we get to the point that all of software engineering
appears to be trivial, we will know the profession has really come of age.
References
1. Cole, Andy. "Runaway Projects—Cause and Effects," Software World, Vol.
26, no. 3, pp. 3-5, 1995.
2. See, for example, Boehm, Barry W. "Software Risk Management: Principles
and Practices," IEEE Software, January 1991, pp. 32-41; Jones,
Capers. Assessment and Control of Software Risks. Englewood Cliffs,
N.J.: Yourdon Press, 1994.
3. Software Project Manager’s Network, SPMN Software Evaluation Model,
Volume II: Project Execution, 2000. Downloadable from www.spmn.com.
4. McConnell, Steve. Rapid Development. Redmond, WA: Microsoft
Press, 1996.
5. Gilb, Tom and Dorothy Graham, 1993. Software Inspection.
Wokingham, England: Addison-Wesley, 1993.
6. O’Connell, Fergus, 1996. How to Run Successful Projects II: The
Silver Bullet. London: Prentice Hall International (UK) Limited, 1996.
Editor: Steve McConnell, Construx Software, 11820 Northup
Way, Suite E200, Bellevue, WA 98008.
E-mail: steve.mcconnell@construx.com
- WWW:
http://www.construx.com/stevemcc/
