Fred Brooks wrote “No Silver Bullet: Essence and Accidents of Software Engineering” in 1987, 12 years after his “Mythical Man Month.” Both offer realistic perspectives on programming in particular and knowledge work in general.
No Silver Bullet
“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 these, one seeks bullets of silver that can magically lay them to rest.
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.
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.”
Fred Brooks in “No Silver Bullet: Essence and Accidents of Software Engineering,”
Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.
Using the werewolf as a metaphor for unpredictable emergent behavior in complex systems is a very clever way to connect to the search for a silver bullet to manage complexity. It took courage for Brooks to predict no easy solution to managing escalating program complexity. In the event he has proven prescient: reuse has increased but there has been no real breakthrough that has increased programmer productivity.
“Details as they glide into view like a pack of werewolves emerging from the fog into the pale moonlight.”
Sean Murphy
Debugging The Specification
“The hardest part of the software task is arriving at a complete and consistent specification, and much of the essence of building a program is in fact the debugging of the specification
[…]
A prototype software system is one that simulates the important interfaces and performs the main functions of the intended system […] The purpose of the prototype is to make real the conceptual structure specified, so that the client can test it for consistency and usability.
Much of present-day software-acquisition procedure rests upon the assumption that one can specify a satisfactory system in advance, get bids for its construction, have it built, and install it. I think this assumption is fundamentally wrong, and that many software-acquisition problems spring from that fallacy. Hence, they cannot be fixed without a fundamental revision that provides for iterative development and specification of prototypes and products.”
Fred Brooks in “No Silver Bullet: Essence and Accidents of Software Engineering,”
Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.
An iterative approach assumes you will have errors in your specification and missing requirements that can only be exposed by building a sequence of prototypes and testing them in both test beds and limited deployments. Much of the value in an iterative approach is that you can use your new appreciation for both what is now possible and the experience of a new capability to refine your methodology and business model.
From Writing To Building to Growing Programs
“Incremental development–grow, don’t build, software. I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.
The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.
Let us turn to nature and study complexity in living things, instead of just the dead works of man. Here we find constructs whose complexities thrill us with awe. The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built.”
Fred Brooks in “No Silver Bullet: Essence and Accidents of Software Engineering,”
Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.
The growth model assumes a co-evolution between software capabilities, team expertise, shared methodologies, and business model. Growth also relies on hierarchy: building complex structures out of simpler structures in configurations with built in redundancy that allow for local experimentation, resiliency, and learning.
Related Blog Posts
- Customer Development is a Sequence of Prototypes
- Seven From Skip Walter’s Laws Of Software Development
- Human Nature As Applied to Software Development
- Eben Moglen: Steel to Software to Collaboration
- Highly Effective Software Development Teams
The highly effective teams I have been a member of used a rapid prototyping approach to help bound uncertainties/risks in the project and delayed making decisions when more information would improve the situation, unless any further delay was effectively a decision. I think that a lot of individual productivity comes from problems avoided by a high level of trust, cooperation, and teamwork.
Pingback: Quotes for Entrepreneurs Collected in February 2018 - SKMurphy, Inc.