# no silver bullet F.Brooks - notes

No Silver Bullet: Essence and Accidents of Software Engineering

by Frederick P. Brooks, Jr.

ref: Brooks, Frederick P., "No Silver Bullet: Essence and Accidents of Software Engineering," Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.

# synthesis

A project can be seen as innocent and straightforward but can become a monster of missed schedules, blown budgets, and flawed products.

Need for a silver bullet to drop software costs.

But there is no silver bullet ; the purpose of the article is to show why by examining :

the nature of the software problem
the properties of the bullets proposed in the past

There is no breakthrough, but there is things to do to improve software engineering, slowly.

There is no royal road, but there is a road.

Nice metaphor with medicine, from magical theories to modern medicine, the road is hard, long, step by step, require discipline but it works better every day.

So it is with software engineering today.

# TLDR

Essential difficulties are the conception parts
Accidental difficulties are the writing parts
All the past and actual breakthroughs concerns writing a software
A software is grown, not built ; so attacking the essentials difficulties means using :
- quick feedback loop
- great designers (great people)

# A - Does It Have to Be Hard?--Essential Difficulties

In comparison to hardware productivity enhancement software engineering is slow. But hardware enhancement is an exception against all others technologies.

Following Aristotle, Brooks divide software engineering difficulties in :

essence difficulties (inherent in the nature of software)
accidents difficulties (difficulties that today attend its production but are not inherent)

The software essence is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions.

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.

If this is true, building software will always be hard. There is inherently no silver bullet.

The inherent properties of this irreducible essence of modern software systems are :

complexity
conformity
changeability
invisibility

# complexity

software systems differ profoundly from computers, buildings, or automobiles, where repeated elements abound
computers are more complex than most things people build, Software systems have orders-of-magnitude more states than computers do
the complexity of the whole increases much more than linearly
the complexity of software is an essential property, not an accidental one
many of the classic problems of developing software products derive from this essential complexity and its nonlinear increases with size

complexity is the source of the difficulty of :

communication among team members (leads to product flaws, cost overruns, schedule delays)
enumerating all the possible states of the program (leads to unreliability)
invoking function (makes programs hard to use)
extending programs to new functions (side effects)
from complexity of structure come the unvisualized states (security trapdoors)
management (remendous learning and understanding burden that makes personnel turnover a disaster)

# conformity

software must conform to interfaces designed by humans (including human institutions and systems), not by nature (or god).
much complexity comes from conformation to other interfaces
cannot be simplified out by any redesign of the software alone

# changeability

the software entity is constantly subject to pressures for change
manufactured things are infrequently changed after manufacture
successful software have a long life
- users pushes new behaviors
- they need to adapt to new hardware

# invisibility

software is invisible and unvisualizable. A building or a machine can be viewed globally with a plan, software are too complex for that
visualizing a software require several diagrams and schemes, each of them is a bias
this cause communication issues

# B - Past Breakthroughs Solved Accidental Difficulties

# High-level languages

it frees a program from much of its accidental complexity
language development approaches closer and closer to the sophistication of users

so there is a maximum gain here

the principal effect of timesharing is to shorten system response time
as this response time goes to zero, at some point it passes the human threshold of noticeability, about 100 milliseconds

so beyond that threshold, no benefits are to be expected

# Unified programming environments

mostly Unix

attack the accidental difficulties that result from using individual programs together, by providing integrated libraries, unified file formats, and pipes and filters

# C - Hopes for the Silver

potential silver bullets :

High-level language advances (Ada, Java, ...)
Object-oriented programming (abstract data types and hierarchical types)
Artificial intelligence (rule-based programming)
Expert systems (put at the service of the inexperienced programmer the experience and accumulated wisdom of the best programmers)
"Automatic" programming (the generation of a program for solving a problem from a statement of the problem specifications)
Graphical programming (software is very difficult to visualize, a software system is not a 3-space dimension realization)
Program verification (much of the essence of building a program is in fact the debugging of the specification not the program itself)
Environments and tools
Workstations

# D - Promising Attacks on the Conceptual Essence

# Buy versus build

The most radical possible solution for constructing software is not to construct it at all.

The hardest single part of building a software system is deciding precisely what to build.
For the truth is, the client does not know what he wants.
it is really impossible for a client to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product

Therefore, one of the most promising of the current technological efforts, and one that attacks the essence, not the accidents, of the software problem, is the development of approaches and tools for rapid prototyping of systems as prototyping is part of the iterative specification of requirements.

The secret is that it (ie : the software) is grown, not built.

# Great designers

The central question in how to improve the software art centers, as it always has, on people.

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.