1
Critique of "No Silver Bullet"
Olinga K. Abbott
Introduction
"No Silver Bullet" expounds Brooks' ideas about the causes of and solutions to
software complexity. The article consists of four principal parts, each with
their own subheading (paraphrased): essential difficulties of software
engineering (SE), past breakthroughs in SE, ideas fallaciously believed to be
solutions to software complexity, and best hopes for the future.
"No Silver Bullet" consists of mostly opinion. Brooks speaks from experience. No
formal research appears to have been undertaken to write the article, and
citations are few.
The article was written in 1987. Fourteen years in computer time is virtually
equivalent to eternity. Even so, the article holds up rather well. Most of the
problems Brooks describes with software complexity remain today. Brooks was
perhaps a bit overly pessimistic; he considered the state of software
engineering at the time to be in crisis. Using Brooks' analysis, modern, even
more complex software should be at a developmental standstill. Yet the cycle of
software development continues apace. Due to the Internet's tendency to quicken
everything it touches, software development cycles even show a shortening
tendency.
The format of this critique is too short for a point-by-point examination of the
source article. The author extracted a few points Brooks makes and examined
those more closely.
2
"Essential Difficulties"
The software profession widely recognizes the four difficulties Brooks mentions
- complexity, conformity, changeability, and invisibility - and little can
really be said about them. Complexity seems to be the most important difficulty,
and underlies most of Brooks' later commentary.
"Past Breakthroughs Solved Accidental Difficulties"
Again, the software profession widely recognizes the three breakthroughs Brooks
describes: high-level languages, time-sharing, and unified programming
environments. Identifying these breakthroughs is relatively easy because the
observations are made in retrospect.
"Hopes for the Silver"
Brooks displays a healthy skepticism in this section. Discussion of the
subheadings of this section follows.
Ada and object oriented programming (OOP)
These two sections are really too dated to be useful. ADA is quickly losing
popularity, Simula-67 is virtually dead, and C++, the OOP language with the
largest following (perhaps now being eclipsed by Java) receives no mention. The
distinction between abstract data types and hierarchical types dumbfounds this
author. C++ templates and Java possessing root classes address the problem of
"type-specification underbrush" Brooks addresses, so OOP may be more beneficial
than Brooks thought.
Artificial intelligence (AI) and expert systems
Brooks dismisses AI because, he says, AI work in one field does not carry over
to another. Brook's conclusion evokes skepticism because pattern recognition
appears to underlie a great amount of human intelligence. If researchers solve
3
the problem of pattern recognition, which will require massive parallel
computing, and if researchers establish that pattern recognition really is the
key to intelligence, AI will have potential in almost every field of computer
software. Abstract thinking, perhaps the other piece of the foundation of human
intelligence, will still be a problem, but effective pattern recognition may
provide at least give an order of magnitude betterment in computer AI.
Automatic programming and graphical programming
Brooks did well to express his skepticism of these gimmicky ideas. Brooks leaves
out one important point: many developers dislike "sloppy" graphical programming
using mice because keyboards are viewed as both more precise and more elegant.
Program verification
Verifying programs mathematically presents a new concept to this author and so
will not be commented on.
Environment, tools, and workstations
Brooks basically states the greatest benefit has already been extracted from
these concepts. No real argument there, especially because common availability
of GUIs present the only real innovation in environments since the article was
written. The concept of developers preferring keyboards over mice, as discussed
earlier, leads to many developers preferring command line interfaces (CLIs) over
graphical user interfaces (GUIs).
Buying instead of building
Brooks only mentions the benefits of buying but not most of the problems. While
buying software usually provides cost savings over building software, buying
software also leaves one at the mercy of the vendor. Not only is the security
system of the purchased software fundamentally unreliable (no way exists to
4
check for back doors, for example), the vendor may eventually charge exorbitant
fees for upgrades, or hold the buyer's data at their mercy in a proprietary
format, thanks to the Digital Millennium Copyright Act that prohibits reverse
engineering in many cases. The issue of buying vs. building may date the article
a bit because open source now provides an increasingly attractive alternative to
buying and building.
Incremental development
Brooks' comments about "growing" vs. "building" software are excellent. The
author uses the growth development model himself, but never knew the growth
model by name. Brooks fails to mention but alludes to an important point: the
need to identify the "core functionality" of the software to be built. When
Brooks states "efforts redouble when the first picture from a new graphics
system appears on the screen", he is really discussing the core functionality.
This core functionality forms the "trunk" of the tree that eventually becomes
the software system. Building the core functionality first is essential in a
growth development model because the core functionality likely will not change
much. Contrast building the core functionality first with building the interface
first: interfaces evolve, and the data the interface presents relies upon the
core functionality. Building an interface before the core functionality may
result in completely rewriting the interface when developers complete the core
functionality.
Problems arise with Brooks' suggestion about using "empty stubs" in an object
oriented programming environment. Well-designed objects should be simple, small,
and easy to test, eliminating the need for the empty stub method. In a
procedural environment the empty stub method may be beneficial, but the author
possesses insufficient procedural programming experience to comment about such a
domain. Problems may arise with using stubs in procedural programs because
5
sometimes knowing what functions the software requires will not be known until
some functions are already in place. Function A calling function B provides an
example. The need for function B cannot always be predicted before writing
function A.
Great designers
Brooks' arguments here appear to be sound, but relying too much on heroes make
businesses leery. The price of heroes can escalate quickly, and dependency on
key employees may leave a business vulnerable when such employees leave especially if they go to work for competitors.
Conclusion
Brooks exhibits great wisdom in "The Silver Bullet". The article required highlevel thinking to write, and the result is a must-read for the software
professional. While perhaps lacking from an academic standpoint due to lack of
empirical evidence, the article possesses great practical value.