Are large language models the “silver bullet” Fred Brooks thought would never come?
https://web.stanford.edu/class/cs99r/readings/parnas1.pdf
https://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=1701944
https://www.newworldencyclopedia.org/entry/Essence
Introduction
In Turing award-winner Fred Brooks’s 1986 piece “No Silver Bullet,” he argued that the process of writing software had already been pared down close enough to attacking the actual meat of programming’s problem space (“essential complexity”) that he predicted there would likely never be the large, order-of-magnitude efficiency improvements in software development like had become customary with the frequent doubling in computer hardware’s computational processing capabilities following Moore’s law.
Brooks likened the process of software project sprawl to a werewolf transformation:
Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For those, we seek bullets of silver that can magically lay them to rest.
The familiar software project has something of this character… usually innocent and straightforward, but capable of becoming a monster of missed schedules, blown budgets, and flawed products. So we hear desperate cries for a silver bullet - something to make software costs drop as rapidly as computer hardware costs do.
Brooks argued that there likely would never be such a “silver bullet:”
But, as we look to the horizon of a decade hence, we see no silver bullet. There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.
…
Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any - no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware. We cannot expect ever to see twofold gains every two years.
Brooks reviewed a few technological advances that had improved development efficiency by that time - high-level languages, time-sharing operating systems, and integrated development environments (IDEs)1. Brooks convincingly argued that these improvements were incidental to the problem space (“accidental complexity”).
Brooks’s horizon
Brooks then analyzed technological improvements still on the horizon that he didn’t believe would move the needle very much - better high-level languages, object-oriented programming, graphical programming, program verification, better environments, tools, and workstations. Brooks argued that the improvements promised by these advances would be marginal, as the bulk of the advance had already been made by ancestor tech breakthroughs.
Most interestingly, however, Brooks also considered the potential impact of artificial intelligence (AI):
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.
Brooks wrote three different sections addressing AI-like systems. The first addresses the type of AI that we are seeing the most advances in today. Brooks gave this short shrift, quickly dismissing its potential almost out of hand:
The techniques used for speech recognition seem to have little in common with those used for image recognition, and both are different from those used in expert systems. I have a hard time seeing how image recognition, for example, will make any appreciable difference in programming practice. The same problem is true of speech recognition. The hard thing about building software is deciding what one wants to say, not saying it. No facilitation of expression can give more than marginal gains.
It’s amusing commentary today given the massive general reasoning capabilities that seem to have been unlocked through large language models’ ability to process language. Or the way that deep learning image classifiers can process auditory inputs when simply transformed to waveform images.
Following the trend at the time, Brooks had a lot more faith in “expert systems” - complex rule engines, powered by a databases of facts, handcrafted by experts, capable of making logical deductions which would help guide programmers along:
How can this technology be applied to the software-engineering task? In many ways: Such systems can suggest interface rules, advise on testing strategies, remember bug-type frequencies, and offer optimization hints.
Consider an imaginary testing advisor, for example. In its most rudimentary form, the diagnostic expert system is very like a pilot’s checklist, just enumerating suggestions as to possible causes of difficulty. As more and more system structure is embodied in the rule base, and as the rule base takes more sophisticated account of the trouble symptoms reported, the testing advisor becomes more and more particular in the hypotheses it generates and the tests it recommends. Such an expert system may depart most radically from the conventional ones in that its rule base should probably be hierarchically modularized in the same way the corresponding software product is, so that as the product is modularly modified, the diagnostic rule base can be modularly modified as well.
The work required to generate the diagnostic rules is work that would have to be done anyway in generating the set of test cases for the modules and for the system. If it is done in a suitably general manner, with both a uniform structure for rules and a good inference engine available, it may actually reduce the total labor of generating bring-up test cases, and help as well with lifelong maintenance and modification testing. In the same way, one can postulate other advisors, probably many and probably simple, for the other parts of the software-construction task.
Many difficulties stand in the way of the early realization of useful expert-system advisors to the program developer. A crucial part of our imaginary scenario is the development of easy ways to get from program-structure specification to the automatic or semiautomatic generation of diagnostic rules. Even more difficult and important is the twofold, task of knowledge acquisition: finding articulate, self-analytical experts who know why they do things, and developing efficient techniques for extracting what they know and distilling it into rule bases. The essential prerequisite for building an expert system is to have an expert.
The most powerful contribution by expert systems will surely be to put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers. This is no small contribution. The gap between the best software engineering practice and the average practice is very wide_perhaps wider than in any other engineering discipline. A tool that disseminates good practice would be important.
The vision of this type of tool
and “automatic” programming (his skeptical quotes):
Brooks dismissed the flavor of AI that we are dealing with today :
https://web.stanford.edu/class/cs99r/readings/parnas1.pdf
Brooks’s promising attacks
Brooks’ parting advice is essentially that if there isn’t any more
we can’t move the needle on developer productivity, that we should work on being
to be smart about allocating developer resources - advice that is still useful today. “Buy versus build” - rather than write a system or library from scratch, use a pre-existing solution (today a sprawling open source ecosystem makes this even easier). “Requirements refinement and rapid prototyping” -
Conclusion
It’s interesting to compare Brooks’ software world of 1986 to ours today. Many of his finer points still ring true today, but the thrust of his essay is a . We are now butting into the end of Moore’s law, while standing at the threshold of unknown limits of AI general reasoning that so far seem to