The next software breakthrough

Bertrand Meyer

A variant of this article appeared in Computer (IEEE), as part of the Component and Object Technology department, in the February 1997 issue.

Five earlier breakthroughs

Although software development evolves less quickly than the field's own hype would suggest, and although the basic issues have remained the same throughout its history, one can identify five breakthroughs since software started to be recognized as a discipline of its own:

• Structured programming: early seventies.
• The C culture (including such concepts as Make, pipes, shells, scripting languages): late seventies.
• The personal computer revolution: mid-eighties.
• Object Technology: early nineties.
• The Internet: now.

A few comments on this list. The approximate times listed do not indicate when the ideas were invented -- object technology, for example, dates back to the design of Simula in 1967 - but when they started to affect a large segment of the industry. Also, the list does not imply a personal judgment that the events noted were intellectually the most important (although I do think they were all beneficial); simply, they are the ones which affected the industry most. Using another criterion would have resulted in a different choice; for example Lisp, although not a breakthrough in the sense used here, was an intellectual milestone. Finally, the third and fifth items are not strictly software advances; as Niklaus Wirth remarked many years ago, our field remains driven for a large part by progress in hardware.

The ones that didn't happen

So what's next? To answer, it is useful to consider two breakthroughs that did not happen. The first one is reuse: although some remarkable reusable software elements have achieved a remarkable degree of success, especially in the Windows world, we have failed so far to realize the vision of re-founding the software field as a components-based industry. The other is formal methods: here too we have seen some isolated successes, and incessant discussions in the pages of such magazines as Computer and Software, but the effect on the industry as a whole is little than a scratch on the surface.

In both cases the reasons usually invoked to explain why progress has been insufficient do not seem quite right to me. For reuse, the common explanation is that we need a better management infrastructure; I discussed this idea in a column last year (February 96) and argued that the major issues are in fact technical. For formal methods, many authors point to the lack of mathematical training of many programmers, and to the constraints of industrial software development.

These explanations are too narrow and miss the basic issue: that reuse can only succeed with some injection of formal methods; and that the only chance for formal methods to make it on the large scale is to be applied to reusable components.

Let me start with the second proposition. Formal methods (such as Z, VDM, Larch, and Abrial's recent B language) apply mathematical techniques to specify software, document it, and whenever possible validate it. In spite many advances towards making these techniques easier to apply, they still require extra effort and some mathematical sophistication. In other words, they add to the development cost, in an industry that already tends to be more focused on productivity (reducing costs) than quality (getting better software in the long term). This explains why the use of formal methods has largely been confined to expensive mission-critical systems -- and in fact to only a subset of such projects.

The new context of software development

But in the context of reusable components things change completely! The extra effort becomes economically justifiable. If you are building a software component of which you hope to sell tens or hundreds of thousands, then all the mathematical apparatus whose ROI looked unwarranted on a one-shot application development now begins to make a lot of sense; if formal techniques enable you to catch just one bug before your component reaches its customers, they will have more than paid for themselves.

Which brings us to the other viewpoint, that of reuse. It is in my opinion foolish to think that the current hopes in new approaches to reuse -- such as CORBA, JavaBeans -- can succeed without some degree of formalism. How can one hope to release thousands of components without systematically including what earlier columns in this department have introduced as the basic form of component specification: the contract, indicating what each component expects from its clients (precondition), what abstract properties it ensures on its results (postcondition), and what global conditions it maintains (invariants). The ominous counter-example was discussed in the January column and in a number of exchanges with readers since then: the $500-million failure of the Ariane-5 rocket launcher, due to the reuse of a component that was not equipped with the proper specification.

In the absence of a systematic approach to reuse based on formal methods, we risk many more Ariane-like failures; and more generally reuse will not take off, as all the propaganda in the world cannot make up for precise, clear specifications. The usual analogy from the hardware field is clear enough here: what hardware engineer would reuse an electronic component without an impeccable specification of its inputs, its outputs, and its operating conditions?

This is the negative view. But the same idea can also be rephrased positively: if we are ready to make the necessary effort to specify and validate our components formally -- an effort that is, as noted, economically justified because of the size of the potential market - then the vision of a component-based software industry can become a reality.

The vision

The vision is indeed exciting: developing a set of unimpeachable components, each with precise specifications, covering one after the other the major areas of computing. They need to be made available in the major languages, from C and C++ to Java; the original versions should be built in Eiffel since it has all the necessary supporting mechanisms (preconditions, postconditions, invariants, a complete inheritance mechanism etc.), making it possible to do a thorough job of specification and validation, and then to translate into other frameworks as needed.

Is this move to a set of formally specified fundamental components desirable? Yes. It is the best thing that could happen to the industry today; I know of no other idea that could do even remotely as much to address software's most crying deficiencies, and to improve just about everything -- productivity, reliability, ease of adaptation -- by a quantum leap.

Will it happen? I don't know. We, the actors in this game -- software developers, software managers, software users -- are the ones who will decide, through our actions more than through our words, whether we really want to carry out the next breakthrough in software.