Issue: July/August 2001 | PDF

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.¹ Conversely, many authorities cite active risk management as one of the most significant contributors to software project success,² and the Software Project Manager’s Network lists risk management first in its list of 16 practices critical for software.³ 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,⁵ 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.¹ A project’s success or failure is often determined within the first 10-20 percent of the project,⁶ 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.⁴

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 10^th 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  |  More articles