No Silver Bullet: Essence and
Accidents of Software
Engineering
Written by
Fredrick P. Brooks in IEEE Computer,
20(4):10-19, April 1987
Presented by
______________________________
Devon Simmonds
Computer Science Department
University of North Carolina Wilmington
______________________________
Devon M. Simmonds
Computer Science UNCW
1
Outline





Research problem / Research objective
Main points/arguments
Strengths
Weaknesses
Significance & Contributions
Devon M. Simmonds
Computer Science UNCW
2
The Problem & Research Goal

Problem: “There is no single development,

Research objective: ”In this article, I shall
in either technology or in management
technique, that by itself promises even one
order-of-magnitude improvement in
productivity, in reliability, in simplicity.”
try to show why, by examining both the
nature of the software problem and the
properties of the bullets proposed.”
Devon M. Simmonds
Computer Science UNCW
3
Software’s Silver bullet!

“The familiar software project, at least as
seen by the nontechnical manager, has
something of this character; it is usually
innocent and straightforward, but is 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.”
Devon M. Simmonds
Computer Science UNCW
4
Silver bullet needed!
Devon M. Simmonds
Computer Science UNCW
5

“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.”
No Software Silver bullet!
Devon M. Simmonds
Computer Science UNCW
6
Why the skepticism?

Essence


Inherent software difficulties
Accidents

Non-inherent software difficulties
Devon M. Simmonds
Computer Science UNCW
7
Brook’s Argument



Premise 1: the hard part of building
software is its specification, design, and
testing.
Premise 2: building software will
always be hard.
Conclusion: There is inherently no
silver bullet.
Devon M. Simmonds
Computer Science UNCW
8
Brook’s Arguments
Software’s Essence




Complexity
Conformity
Changeability
Invisibility
Devon M. Simmonds
Computer Science UNCW
9
Brook’s Arguments
Software’s Essence:


Complexity
Software more complex than other human constructs.
 Software have order of magnitude more states than computers.
There are about
1014
possible
paths! If we
execute one test
per millisecond,
it would take
3,170 years to
test this
program!!
Devon M. Simmonds
loop < 20 X
How many paths?
 Computer Science UNCW
10
Brook’s Arguments
Software’s Essence:


Complexity
Complexity grows non-linearly with size
There are about
1014
possible
paths! If we
execute one test
per millisecond,
it would take
3,170 years to
test this
program!!
Devon M. Simmonds
How many paths?
 Computer Science UNCW
11
Brook’s Arguments
Complexity
Complexity 
Software’s Essence:
Software Size 

Complexity grows non-linear with size.
Devon M. Simmonds
Computer Science UNCW
12
Brook’s Arguments
Software’s Essence:

Software development lacks unifying
rules and theories.


Conformity
man made not God made.
Software must conform to many
interfaces.

Cannot be simplified by software redesign
only.
Devon M. Simmonds
Computer Science UNCW
13
Brook’s Arguments
Software’s Essence:



Changeability
Hardware devices modified much less
than deployed software programs.
Software is infinitely malleable.
All successful software get changed.


Users invent new uses for software.
Software outlives hardware  software
redesign.
Devon M. Simmonds
Computer Science UNCW
14
Brook’s Arguments
Software’s Essence:

Invisibility
Software is invisible and unvisualizable


Software reality not embedded in space 
no ready geometric representation.
Made up of several general directed
graphs.
Devon M. Simmonds
Computer Science UNCW
15
Brook’s Arguments
Software’s Essence

Past breakthroughs solved accidental
difficulties.



High-level languages.
Time-sharing
Unified programming environments
Devon M. Simmonds
Computer Science UNCW
16
Brook’s Arguments
Software’s Essence

Hopes for Silver.



Ada & HLL Advances.
OOP
AI


Expert Systems
Etc.
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.
Devon M. Simmonds
Computer Science UNCW
17
Brook’s Arguments
Software’s Essence

Promising Attacks.



Buy vs. build
Requirements refinement and rapid prototyping
Great designers

“We can get good designs by following good practices instead
of poor ones.”

“Nevertheless, I do not believe we can make the next step

“I think the most important single effort we can mount is to

Devon M. Simmonds
upward in the same way. Whereas the difference between poor
conceptual designs and good ones may lie in the soundness of
design method, the difference between good designs and great
ones surely does not. Great designs come from great designers.
Software construction is a creative process. Sound methodology
can empower and liberate the creative mind; it cannot inflame
or inspire the drudge.”
develop ways to grow great
designers.”
Computer Science UNCW
18
Analysis
Strengths



Addresses an important but difficult
subject.
Differentiation between essential
and accidental factors.
Emphasis on software design.
Devon M. Simmonds
Computer Science UNCW
19
Weaknesses:



Argument invalid/unsound
Premise 1: the hard part of building
software is its specification, design, and
testing.
Premise 2: building software will
always be hard.
Conclusion: There is inherently no
silver bullet.
Devon M. Simmonds
Computer Science UNCW
20
Analysis
Weaknesses II


Pessimistic.
Software is not unvisualizable!



Multiple views does not mean unvisualizable.
Model-driven development not addressed
– focus is on programming.
Probably there is need for a paradigm
shift rather than a technological shift.
Devon M. Simmonds
Computer Science UNCW
21
Analysis
Significance/Contribution



Brought to the fore the inherent
difficulties in building software.
Brought to the fore the need to
rethink/re-evaluate software
development approaches.
Differentiated between essential and
accidental complexity.
Devon M. Simmonds
Computer Science UNCW
22
References


Brad Cox, What if there's a Silver
Bullet... And the Competition Gets
it First?
Brad Cox, No Silver Bullet Revisted,
American Programmer Journal,
November 1995.
Devon M. Simmonds
Computer Science UNCW
23
Summary


In this class we critiqued:
 Fred Brooks, “No silver bullet: Essence and
accidents of software engineering,” IEEE
Computer, 20(4):10-19, April 1987.
 W.W. Gibbs, “Software's Chronic Crisis,”
Scientific American, pages 72-81, September,
1994.
READING for next class: papers ??
Devon M. Simmonds
Computer Science UNCW
24
Qu es
ti ons?
______________________
Devon M. Simmonds
Computer Science Department
University of North Carolina Wilmington
_____________________________________________________________
Devon M. Simmonds
Computer Science UNCW
25
A Rational Design Process:
How or Why to Fake It
Written by
D. L. Parnas and P C Clements
in IEEE Transactions on Software
Engineering, 12(2):251-257, IEEE Press
1986
Presented by
______________________________
Devon Simmonds
Computer Science Department
University of North Carolina Wilmington
______________________________
Devon M. Simmonds
Computer Science UNCW
26
Summary Template

Let’s discuss this paper using this outline.







Research problem
Research objective(s)
Main points/arguments
Quality of related work
Strengths/ Weaknesses
Significance & Contributions
Relevance to the silver bullet discussion
Devon M. Simmonds
Computer Science UNCW
27
for SLIDE 6
Key Questions in approaching a research
paper




What problem is being investigated? i.e., what is the paper about?
What kind of paper is it?
What are the author’s arguments?
What results did the investigator obtain?







What new knowledge was contributed?
What previous work does the paper build on?
How is the result different from and better than prior work?
What, precisely and in detail, is the new result?
How does this paper fit in?
What are the strengths and weaknesses of the paper?
What is the contribution/significance of the paper






What question did you answer?
Why should the reader care?
What larger question does this address?
Why should the reader believe the result?
What standard should be used to evaluate the claim?
What concrete evidence shows that the result satisfies the claim?
Devon M. Simmonds
Computer Science UNCW
28
28