No Silver Bullet, April 1987
No Silver Bullet: Essence and Accidents of Software Engineering by Frederick Brooks was published in Computer magazine in April 1987, just as I was graduating from college. I stumbled upon this paper recently and read it again. It is interesting to see how little has changed in the intervening 18 years.
It was fun to read a paper written in 1987 about the future of programming/software development. It is amazing how accurate/applicable it is today still.
I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems.
If this is true, building software will always be hard. There is inherently no silver bullet.
Isn’t that the case – we can make programming inexpensive, but software development is always hard. Not because writing software is hard (it takes training, time, skilled labor) but because specifying what you want unambiguously, clearly, concisely is really hard. And as the complexity, the scope of the systems grow beyond what a single individual can hold in their head – it gets nightmarishly hard.
In the section on “Hopes for the Silver”, I laughed at this quote:
Nevertheless, Ada will not prove to be the silver bullet that slays the software productivity monster. It is, after all, just another high-level language, and the biggest payoff from such languages came from the first transition the transition up from the accidental complexities of the machine into the more abstract statement of step-by-step solutions.
Now, I wasn’t laughing at the fact that people thought Ada would be a silver bullet (they really did). I wasn’t laughing at the Ada language (it was quite good actually – PL/SQL looks a ton like Ada). I was laughing at the fact that if you replace Ada with a somewhat popular language of today – the statement still stands!
Object-oriented programming. Many students of the art hold out more hope for object-oriented programming than for any of the other technical fads of the day…. Nevertheless, such advances can do no more than to remove all the accidental difficulties from the expression of the design. The complexity of the design itself is essential, and such attacks make no change whatever in that. An order-of-magnitude gain can be made by object-oriented programming only if the unnecessary type-specification underbrush still in our programming language is itself nine-tenths of the work involved in designing a program product. I doubt it.
I doubt it too. I remember in 1987 – people were thinking that software development would not exist as we know it in the 2000’s. All of the software that ever needed to be developed would have been developed and we’d cobble together applications by assembling components. We wouldn’t have programmers, but more of an army of assemblers, tying together all of these pre-existing bits and pieces into applications on the fly. It didn’t really happen. In fact, I see little real world reuse of software. Sure, we have class libraries in the millions, but they are little more than the utility packages I used to develop in the past (we called it modular coding back then). They solve bits and pieces of a problem but are not major components. Maybe it is the environment I work in, but I don’t see huge amounts of reuse happening, not with business components anyway.
Artificial intelligence. Many people expect advances in artificial intelligence to provide the revolutionary breakthrough that will give order-of-magnitude gains in software productivity and quality. I do not. To see why, we must dissect what is meant by "artificial intelligence."
Ah, AI, it was going to save the day. It along with Expert Systems and Natural Language Processing. Any software worth its bits and bytes had the AI or Expert System tag associated with it. Now, like CASE, people distance themselves from those terms, as the end product was so far removed from the promise. Expert Systems actually worked though, they were just oversold. They still exist today, you might even say there is an expert system in the database – it applies the ROT, rules of thumb, to the metrics and making sometimes reasonable suggestions based on it.
Graphical programming. A favorite subject for PhD dissertations in software engineering is graphical, or visual, programming the application of computer graphics to software design. Sometimes the promise held out by such an approach is postulated by analogy with VLSI chip design, in which computer graphics plays so fruitful a role. Sometimes the theorist justifies the approach by considering flowcharts as the ideal program-design medium and by providing powerful facilities for constructing them.
Nothing even convincing, much less exciting, has yet emerged from such efforts. I am persuaded that nothing will.
He got that right. Back then, it was all about the exciting IDE’s that were coming out. The integration of CASE with the programming environment. Boxes, arrows, flows, automatic documentation, and so on. Problem was, we couldn’t describe the problem we were trying to solve and it didn’t matter how pretty of an environment you had. If you don’t understand the problem, all of the pictures in the world won’t help you.
Buy versus build. The most radical possible solution for constructing software is not to construct it at all.
That guy was pretty forward looking for his time. Not many of the application vendors you know of today even existed back then. The stuff we take for granted today, didn’t exist. It was just being started, just being formed. I think he got that one right, dead on. There is the real code reuse, forget OO, just buy the stuff.
Anyway, it is an interesting read if you have the time. If you were in the industry back then, it is a good “time travel” paper (see table 1, “Exciting vs. useful but unexciting software products”). The main gist is at the bottom:
My first proposal is that each software organization must determine and proclaim that great designers are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded. Not only salary, but the perquisites of recognition office size, furnishings, personal technical equipment, travel funds, staff support must be fully equivalent.
Great designers, not coders. People who can put it all together. I think he got that right (but we still aren’t there yet).