2
Editor’s Corner No Silver Bullet: A Look at Software Research Via the Fred Brooks Article* For a couple of decades now, computing research has provided a promise of dramatic breakthroughs in soft- ware productivity. For a variety of reasons, however, the promise has, for the most part, not been fulfilled. Breakthroughs have simply not occurred. A new viewpoint is emerging on this issue. That viewpoint holds that breakthroughs are simply not going to be forthcoming. The new viewpoint is emerging from the best and brightest minds of the computing field. The first to speak out was David Pamas. Pamas, in his series of papers attacking the Star Wars project, also attacked research in the software field, finding it did not-in fact, could not-lead to breakthroughs in prac- tice, and called some of it “dangerous and misleading. ” His position was described in an earlier “Editor’s Comer.” Now that viewpoint has been reinforced. Fred Brooks, the author of what is almost undoubtedly the single most important book in the computing field, The Mythical Man-Month, and once the manager in charge of the massive OS/360 project, has come out with an echo and a reinforcement and some new thoughts on this same issue. The Brooks position is taken in a paper published in IEEE Computer in April 1987. It is rapidly becoming known as the “Silver Bullet” paper, because it likens software engineering’s fundamental problems to werewolves, which can only be slain by silver bullets, and then goes on to establish that there are no silver bullets in the software field. What does Brooks say? Lots. For one thing, he takes the position that the process of building software is hard and always will be. It is hard because of its inherent and necessary complexity: “software entities are more complex . . . than perhaps any other human construct,” “software systems have orders-of-magnitude more states than computers do,” and “the complexity of software is an essential property” which cannot be wished away by the techniques of other disciplines such *This editorial was reprinted with permission from the column “Software Reflections” in the periodical System Development (P.O. Box 9280, Phoenix, AZ 85068). The Journal of Systems and Software 7, 181-182 (1987) 0 1987 Elsevier Science Publishing Co., Inc., 1987 as mathematics where simplified models of complex problems are useful problem-solving tools. Having established that software is hard and always will be, Brooks dissects, one by one, the research directions of software theorists and, just as Pamas did, finds them wanting. Ada and the other high-level languages are just new languages, not much more. Object-oriented programming is exciting, but will only produce a breakthrough-and Brooks doubts it will- if “the unnecessary type-specification underbrush still in our programming language is itself nine-tenths of the work . ..” Brooks pretty well agrees with Pamas that artificial intelligence won’t be a breakthrough either. Automatic programming is only useful in applications with particularly “favorable properties, ’ ’ and Brooks sees few such applications. Graphical programming doesn’t offer anything either “convincing” or “exciting.” Program verification does not necessarily result in error- free programs and costs more than current methodo- logies such as testing and walkthroughs. Environments and tools will, from now on, only result in marginal improvements. Powerful workstations can only do the same. It is not that the directions are not promising, Brooks says. It is just that the big steps in productivity were already taken by such advances as the first high-order language, and time-sharing, and the existence of unified programming environments such as Unix and Interlisp. What is left, the advances to be achieved by the current search for silver bullets, will lead to considerably less relative advancement. The day of the dramatic break- through in software engineering, Brooks suggests, may be behind us. But Brooks doesn’t stop there. If we cannot get dramatic productivity improvements through current research directions, then where might we get them? He suggests some more mundane yet promising avenues. 181 0164-1212/87/$3.50

Editor's corner: No silver bullet: A look at software research via the fred brooks article

  • View
    213

  • Download
    1

Embed Size (px)

Citation preview

Page 1: Editor's corner: No silver bullet: A look at software research via the fred brooks article

Editor’s Corner

No Silver Bullet: A Look at Software Research Via the Fred Brooks Article*

For a couple of decades now, computing research has provided a promise of dramatic breakthroughs in soft- ware productivity. For a variety of reasons, however, the promise has, for the most part, not been fulfilled. Breakthroughs have simply not occurred.

A new viewpoint is emerging on this issue. That viewpoint holds that breakthroughs are simply not going to be forthcoming. The new viewpoint is emerging from the best and brightest minds of the computing field.

The first to speak out was David Pamas. Pamas, in his series of papers attacking the Star Wars project, also attacked research in the software field, finding it did not-in fact, could not-lead to breakthroughs in prac- tice, and called some of it “dangerous and misleading. ” His position was described in an earlier “Editor’s Comer.”

Now that viewpoint has been reinforced. Fred Brooks, the author of what is almost undoubtedly the single most important book in the computing field, The Mythical Man-Month, and once the manager in charge of the massive OS/360 project, has come out with an echo and a reinforcement and some new thoughts on this same issue. The Brooks position is taken in a paper published in IEEE Computer in April 1987. It is rapidly becoming known as the “Silver Bullet” paper, because it likens software engineering’s fundamental problems to werewolves, which can only be slain by silver bullets, and then goes on to establish that there are no silver bullets in the software field.

What does Brooks say? Lots. For one thing, he takes the position that the process of building software is hard and always will be. It is hard because of its inherent and necessary complexity: “software entities are more complex . . . than perhaps any other human construct,” “software systems have orders-of-magnitude more states than computers do,” and “the complexity of software is an essential property” which cannot be wished away by the techniques of other disciplines such

*This editorial was reprinted with permission from the column “Software Reflections” in the periodical System Development (P.O. Box 9280, Phoenix, AZ 85068).

The Journal of Systems and Software 7, 181-182 (1987)

0 1987 Elsevier Science Publishing Co., Inc., 1987

as mathematics where simplified models of complex problems are useful problem-solving tools.

Having established that software is hard and always will be, Brooks dissects, one by one, the research directions of software theorists and, just as Pamas did, finds them wanting.

Ada and the other high-level languages are just new languages, not much more.

Object-oriented programming is exciting, but will only produce a breakthrough-and Brooks doubts it will- if “the unnecessary type-specification underbrush still in our programming language is itself nine-tenths of the work . ..”

Brooks pretty well agrees with Pamas that artificial intelligence won’t be a breakthrough either.

Automatic programming is only useful in applications with particularly “favorable properties, ’ ’ and Brooks sees few such applications.

Graphical programming doesn’t offer anything either “convincing” or “exciting.”

Program verification does not necessarily result in error- free programs and costs more than current methodo- logies such as testing and walkthroughs.

Environments and tools will, from now on, only result in marginal improvements.

Powerful workstations can only do the same.

It is not that the directions are not promising, Brooks says. It is just that the big steps in productivity were already taken by such advances as the first high-order language, and time-sharing, and the existence of unified programming environments such as Unix and Interlisp. What is left, the advances to be achieved by the current search for silver bullets, will lead to considerably less relative advancement. The day of the dramatic break- through in software engineering, Brooks suggests, may be behind us.

But Brooks doesn’t stop there. If we cannot get dramatic productivity improvements through current research directions, then where might we get them? He suggests some more mundane yet promising avenues.

181

0164-1212/87/$3.50

Page 2: Editor's corner: No silver bullet: A look at software research via the fred brooks article

Editor’s Comer

1.

2.

3.

Buy software rather than building it whenever you can. Package software is more practical in the 1980s than it was in the 196Os, Brooks suggests, not because we know more now about how to build such packages, but because the relative cost of software is now so high (compared to hardware) that businesses are more likely to tailor the way they function to a software package than the opposite.

Use incremental approaches to building software. Refine requirements for software by prototyping. Develop software incrementally, so that partial solu- tions to the problem are available early in the development cycle. If the process of building soft- ware is truly hard and always will be, then that process must be attacked by some fundamental new approaches.

Remember that great software designs come from great designers. Creative software people must be hired and nourished. Brooks suggests such nourish- ment as (a) identifying top designers as early as possible-the best are not necessarily the most experienced; (b) assign a career mentor to each top

prospect; (c) devise and maintain a career develop- ment plan and a career file for each; and (d) provide opportunities for these people to interact with and stimulate each other.

So what, in retrospect, have Pamas and Brooks said to us? That software development is a conceptually tough business. That magic solutions are not just around the comer. That it is time for the practitioner to examine evolutionary improvements rather than to wait-or hope-for revolutionary ones.

Some in the software field find this to be a discourag- ing picture. They are the ones who still thought breakthroughs were near at hand.

But some of us-those of us crusty enough to think that we are realists-see this as a breath of fresh air. At last, we can focus on something a little more viable than pie in the sky. Now, perhaps, we can get on with the incremental improvements to software productivity that are possible, rather than waiting for the breakthroughs that are not likely to ever come.

Thanks, David Pamas and Fred Brooks, for clearing the way.