How many people remember that on February 28, 2001, Seattle was hit by a magnitude 6.8 earthquake? The earth wobbled like Jell-O, people were rushed out of buildings, traffic lights swung, there was significant damage in places. But the city remained intact. No major buildings collapsed and at most one death could be attributed to the quake.
By contrast, a magnitude 6.1 earthquake that hit El Salvador the same month caused hundreds of deaths.
Although I was in downtown Seattle at the time, I had to look up what year it occurred, much less the day. The ability to forget a 6.8 earthquake was the gift of some very fine engineers. If the people of Seattle fully understood what happened on February 28th, 2001 (or rather, what did not happen) they would have erected a statue to the Unknown Civil Engineer. I am not noted as an earthquake survivor; I have no dead family or friends to mourn. The civil engineering community took a 6.8 earthquake and made it about as boring as it could possibly have been.
It is interesting to compare civil engineering with the software industry. According to Weinberg’s Second Law, “If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.” Certainly, a review of the Risks Digest, a moderated forum devoted to computer-related failures, makes for sober reading.
The Standish Group, which has studied tens of thousands of projects, puts the overall IT project success rate at 34% − a significant improvement over the last ten years, attributed to the increasing use of iterative software development methodologies.
The importance of iterative methodologies to successful software development is significant. Iterative methodologies involve designing and building software in a series of small stages, learning along the way from the previous stages.
While it is never described this way, iterative development amounts to systematized novice behavior. An expert sees the solution to a problem and goes straight to it; a novice takes a step, checks if he seems to have gone in the right direction, then takes another (tentative) step. The rise of the iterative development methodologies is essentially the tacit admission that the software industry does not quite know what it is doing.
To be fair, the challenge faced by software engineers is unprecedented. Every other engineering discipline is limited by the properties of materials; software is limited only by the properties of information (which is to say, complexity). Consequently, the problems faced by software engineers are more difficult than any the engineering community has ever been exposed to before.
Faced with an Everest of difficulty, success is possible only with care and humility. Iterative development moves in this direction, but a more general need is to systematically manage the feedback loops necessary to keep a project successful. Feedback loops reduce the number and magnitude of surprises; put more simply, feedback helps keep projects boring.
An important step forward is to explicitly combine an iterative methodology with systematic feedback from the end-user community. This step has been taken with the JackBe Application Methodology (JAM), which combines the iterative Rational Unified Process (RUP) with User-Centered Design (UCD).
Will feedback loop management by itself solve the software reliability problem? Certainly not. Another key problem is that software development tools in general use have not improved fundamentally since the 1970s, in terms preventing certain kinds of flaws from occurring.
We can only do what we can; but we must do no less than that. The software industry has a long way to go before it can say the equivalent of “You can take a 6.8 earthquake and forget about it. We’ve got you covered.” But that is the road we must be on.
