In the past few decades, three "big hitters" have stepped up to the plate of building better software-formal methods, tools, and process improvement initiatives. Unfortunately, they have all struck out, according to James Whittaker in this week's column. Read on for his critique of these supposed cure-alls and for his call for a new kind of player on the field.
In the late 1970s the software quality problem was all too apparent. Software was hard to write, hard to maintain, and often failed to meet its requirements. Even at this early stage in the history of software engineering, a move was afoot to correct this problem. Beginning with structured programming, researchers studied better ways to write code. The push for formal methods began. If you'd only do things more formally, the plea went, your code would be better! A few even went so far as to make "zero defects" their Holy Grail. The search was on. Unfortunately, the search still continues.
Following close on the heels of the formal methods advocates were the tool vendors. If you'd only use the right tools, they cried, your code would be better! Many tools have greatly simplified the task of developing software. Development organizations spend hundreds of thousands of dollars on tools. Software is still buggy.
The latest entry into the fray has been the process improvement people. If you'd only work more carefully, they beg, your code would be better! Now our managers are as busy as our developers. Developers not only have software to develop but also make-work reports to write. Software is still buggy.
This article discusses these three "silver bullets" and exposes their Achilles' heels. I suggest that the answer to the problem must, by definition, be technical-not managerial-in nature. I end by launching the search for a fourth proposal.
Formal methods are a great idea. Essentially, they equate programming a computer to solving a math problem. You can go about it using a mixture of creativity, intelligence, and lots of practice solving similar problems. However, there are a couple of problems with formal methods that can't be overlooked.
First and foremost, software developers won't use them. This puzzles formal methods advocates to no end. However, it's fairly plain to the rest of us: no one can show developers just how to apply formal methods. The examples in books and papers are far too simple to scale the ideas to real development problems. Plus, once you get outside your comfort zone, the formal methods fall apart. You remember how you felt when you learned calculus after mastering algebra? Algebra problems were easy because you'd solved hundreds of them. But the methods you used didn't seem to apply to calculus problems. All the rules had changed. It turns out this same situation plagues software problems too. They can be as different as algebra and calculus. Why should we be surprised that what works on one problem is useless on another? Formal methods don't scale in software because they don't scale in mathematics either.
Second, one can use formal methods and still write buggy code. Formal methods don't address anything but the algorithm. But we all know that an algorithm can be correct on paper but fail on a real computer. The problem is that real computers have space and time limitations, other applications, and very complex operating systems that must be dealt with by code that has nothing to do with the main algorithms of an application. Indeed, code to process inputs and handle errors is often much larger and more complex than the algorithm that actually gets the main work done. There are no formal methods for handling such code.
Formal methods are important, but they will only take you so far toward reliable software. Strike one.
Tools can make the software development task much less painful but they cannot guarantee zero defects; in fact, they cannot even guarantee fewer bugs. Since the tools themselves can