In the essay No Silver Bullet, Refired, Brooks reexamines his essay No Silver Bullet (aka NSB or last week’s re-read) nine years after its original publication date. Both essays were additions to original 1974 The Mythical Man-Month as Brooks sought to project the course of the software development industry. As sadam510 pointed out on the blog last week, we have passed out of the traditional Re-Read territory and are now cutting through ‘fresh’ snow. NSB was originally published in 1986, and NSB, Refired was published nine years afterwards both to address the criticisms and to examine how the world had progressed.
Brooks begins the essay by addressing some of the misunderstandings that were generated by his particular brand of prose (several readers have commented that these later essays are a reflection of Brook’s involvement in academia, that is, the straight-on writing style of the earlier essays had become more difficult to understand). The first of the misunderstandings he tacked was the distinction between essence and accident. Brooks reminds the readers that the word ‘accident’ was used to mean incidental. The essence of a software application is the logic needed to solve the business problem, while the coding language or development environment are incidental to solving the business problem. The second point of misunderstanding focuses on the how much of the effort or complexity of creating an application was caused by incidental factors versus the essence. Brooks argued in NSB that the essence was the most significant factor, and in NSB Refired he reiterated that stance. While both essence and accidental are meaningful, in order to generate an order of magnitude change, the complexity of the essence must be reduced.
The second thread in the essay featured a rebuttal of David Harel‘s analysis/criticism. Brooks felt that Harel’s criticism was one of the most well-formed, therefore he spent significant effort to rebut it. Harel criticism begins by arguing that Brooks’s conclusions were pessimistic and gloomy. On the pessimistic side Brooks defended his perspective by suggesting he is at worst he was realistic based on his developer’s background. Developers tend to be optimistic about the ability to solve ANY problem (note Dr. Ricardo Valerdi in his interview on SPaMCAST 84 provided evidence to support this position). Brooks stated that taking an overly rosy view as suggested by Harel of the potential for change was a pipe dream. In Brooks’s opinion, pipe dreams do not create the pressure needed for progress. On the topic of gloomy, Harel suggested that Brooks perspective grew out of three sources:
- The sharp delineation between essence and accident, which he believed was artificial.
- The 10-year time horizon used by Brooks was overly short.
- Analyzing each silver bullet separately ignored the relationships and potential synergy between the potential silver bullets.
As a thought experiment in the critique, Harel applied the essence and accident analysis Brooks used in the NSB to the development world of 1952. Harel suggests the structure used by Brooks would only fit in a very specific timeframe, and therefore, would not necessary hold in the future. Brooks rejects the thought experiment by pointing that as soon as large-scale systems began to be addressed (approximately 1954), the analysis approach works.
Harel completed his criticism by proffering his own silver bullet based on a system of modeling the concepts of the application (in Brooks’s language, the essence). There was an undercurrent in the essay that many of those criticizing NSB were doing so to suggest a silver bullet. In this case, while Brooks agreed with the idea of leveraging models to identify and develop the conceptual basis of the application, he noted that most developers develop their own highly individualized conceptual models of what they are working on and that they are not typically generalizable.
Another class of criticisms suggests that Brooks’s focus on productivity in NSB was misplaced. Rather, as noted by Caper Jones (former boss, friend, and mentor), the focus should be on quality and then productivity will follow. Brooks suggests whether focusing on quality or productivity the conclusions of the NSB don’t change. (I think I will ask Capers his opinion…)
After reviewing the criticisms, Brooks circles back to review what has happened to productivity in the years between NSB and NSB, Refired. Capers Jones’ data suggests that for comparable programming languages it had productivity had increased three-fold; while Ed Yourdon had evidence of up to five-fold increases. Large changes, but as Tom DeMarco indicated, not an order of magnitude increase. In order to understand where the productivity improvement had come from Brooks re-examined some the major categories from the NSB.
Build versus buy had become a powerful tool (and still is in 2015). The ability to customize software packages easily has continued to increase the power of commercial off-the-shelf software. Packages like SAP and PeopleSoft are perfect examples of the increased productivity configurable/customizable packages deliver.
Brooks suggests that object oriented development (OO) represents at least a brass bullet. OO has delivered value and continues to show promise. Even today OO continues to grow in use and value (even though OO has not fundamentally changed productivity by an order of magnitude and is therefore, no silver bullet). In hindsight from 2015, OO has continued to penetrate and deliver value, but it has not changed the world . . . yet.
Reuse Brooks found was being done in pockets but that it had not spread to the degree he had suggested in NSB would be needed to actually be a silver bullet. The advent of natural language programming languages may have inadvertently added complexity to adopting reuse programs. Natural languages make finding patterns to reuse harder. While not an insurmountable problem, they add complexity, effort and the killer – cost, which has slowed the adoption of reuse. My personal observation from 2015 suggests that reuse is still a marginal practice due to the overhead required to identify and package generalized functions.
In the end, despite all of the criticisms and critiques, Brooks’s position is unchanged. He states that “complexity is the business we are in and complexity is what limits us.” Until complexity is conquered there will be no silver bullets, only incremental improvements. Not that incremental improvement are anything to sneeze at!
Programming Notes: My version of the Mythical Man-Month includes one large essay, The Mythical Man-Month after 20 Years and an epilogue. I suspected we will complete the Re-Read in two weeks. Suggestions for the next book in the series?
Previous installments of the Re-read of The Mythical Man-Month
The Mythical Man-Month (The Essay)
Aristocracy, Democracy and System Design
Why did the Tower of Babel fall?
Ten Pounds in a Five–Pound Package
No Silver Bullet – Essence and Accident In Software Engineering
November 15, 2015 at 6:58 pm
Agree, Brook’s target audience has definitively changed in this chapter from the the practitioner to academia. It reminds of the director cuts you find on some DVDs, most viewers are only interested in the full feature movie.
Brook’s is asking and answering a very important question: what in software development has improved and not improved so much over the last 20 years?
I want to focus my response on an area Brook’s wrote about in the previous chapter and one that I currently wrestle with.
p. 199 “The hardest single part of building a software system is deciding precisely what to build.”
Some use Lean techniques in software today to discover the right thing in software to build.
SPaMCAST 342 – Gorman, Gottesdiener, Discover to Deliver Revisited
discusses this subject and is an excellent Podcast to re-listen to.
PMI is now offering training and certification as a “Professional in Business Analysis” (PBA).
During “The Mythical Man-Month” time period (20 years), the recognition of “What to build?” emerges as an equally important question as “How to build it?”.
—
Thomas: next re-read, consider Jim Highsmith’s “Agile Project Management” (2nd edition, copyright 2010).
November 16, 2015 at 1:42 am
Thanks for the suggestion. Also considering the Checklist Manifesto?