Ivar Jacobson is a father of components and component architecture, use cases, aspect-oriented software development, UML, and the Rational Unified Process. Bertrand Meyer is one of the pionners of object technology and the designer of the Eiffel method and language. He is Chief Architect of Eiffel Software and Professor of Software Engineering at ETH Zurich.
For someone in search of a software development method, the problem is not to find answers; it's to find out how good the proposed answers are. We have lots of methods -- every year brings its new harvest -- but the poor practitioner is left wondering why last year's recipe is not good enough after all, and why he or she has to embrace this year's buzz instead. Anyone looking for serious conceptual arguments has to break through the hype and find the precious few jewels of applicable wisdom.
In this note we argue that work on software development methodology must undergo a profound transformation. It should renounce its current reliance on fashion and political-style propaganda, turning instead to a serious scientific endeavor based on theory and experimental validation.
Fashion, Politics, or Engineering?
Software methodology is a strange field. In principle it should be a science-based engineering discipline, but in practice it looks at times like the fashion industry, and at time like politics.
As in the fashion industry, every new year brings a new style, and in their hurry to keep up people throw away the good with the bad. Instead of learning from their own experience, they start with something they believe must be better since everyone else says it's better. Contrary to the complaint -- common among innovators -- that large companies are slow to embrace change, many are eager to try out new things; the true problem is that they abandon them even more quickly, discarding expensive investments in processes and tools before having had a chance to apply them seriously. Everything is marketed to the trend setters and early adopters. We accept this for clothing, but with the size of our software investment and its importance for society this is wasteful and irresponsible.
As in politics -- more accurately, bad politics -- the emphasis is not on substantial solutions to hard problems, but on slogans, propaganda, and emotions. Ideas are not presented through careful discussions of pros and cons, but marketed like brands; they are spread by gurus delivering the Holy Word. Each approach tries to ignore its neighbors; if it has to acknowledge them, it is usually to berate them. The practitioner is left to wonder whom to believe.
In the end few new ideas ever get applied on a large scale, so that little changes in what counts: quality, productivity, and lead time in the development of large systems. For all the hoopla in software methods over the past 40 years, only a handful of major innovations -- structured programming, object technology, design patterns, UML, and so on -- have truly affected how the industry works.
These are signs of immaturity. The discipline needs to become adult.
Agility
The latest wave to sweep the industry is "agile". Agile methods have made a number of significant contributions and reminded us of the central role of people in software engineering. Some of the agile lessons are likely to remain in future methods.
At the same time, the agile field provides a vivid example of some of the phenomena cited above. For a movement that values people over process and tools, agility has given us many processes and tools advertised as "new", without making the effort to describe what is truly different and what is a restatement of known ideas. Practitioners are understandably confused. Regardless of the value of the ideas, it is striking to see how they are promoted: the elegantly written foundational document of the approach is a "manifesto", long on emotional appeals in the first person plural ("We have come to value") and short on facts. This style may be effective to capture attention, but as ideas mature it should yield to more traditional (even if also more boring) forms of argumentation.
In engineering and science, the originators of a new technique -- eager, like any other human beings, to promote their invention -- are careful to work out where its application is inadequate or unproven Few software methodologists bother with such intellectual safeguards. Too many exaggerate the differences with previous approaches. For one paradigm shift (such as object technology), how many supposed breakthroughs are adaptations of known ideas? There is nothing wrong with incremental improvements; much of the progress in science and engineering happens that way. But it makes no sense to disguise every increment as a revolution.
