"No Silver Bullet" Refired

By Ryan Ruzich "No Silver Bullet" Refired

NSB • Asserts and argues that no single software engineering development will produce an order-of-magnitude improvement in programming productivity within ten years (from the papers publication in 1986).

Objection #1 “Some things not Clear” • Accident-He used the ancient usage going back to Aristotle. • By Accidental, he did not mean “occurring by chance” nor “misfortune” • More appropriate would have been “incidental” or “appurtenant”

Objection #1 “Some things not Clear” • The part of software building called essence in NSB is the mental crafting of the conceptual construct. • The Part called accident is its implementation process.

A question of Fact • Author’s opinion that the accidental or representational part of software design is down to about half or less of the total time. • NSB argues that if the accidental part of the work is less that 9/10, shrinking it to zero will not give an order of magnitude improvement.

There is a Silver Bullet • Paper written by Brad Cox the argues eloquently for the reusable, interchangeable component approach as an attack on the conceptual essence of the problem.

A simple misunderstanding • The author was not arguing that the challenges facing SE back then would still be plaguing us today, but rather that even if we surmounted those obstacles, which we did, new ones would arise. • Complexity is still the biggest challenge, no matter what language or time period for SE.

Harel’s Analysis • David Harel in the 1992 paper “Biting the Silver Bullet” undertakes the most careful analysis of NSB that has been published.

Pessimism vs. optimism vs. realism • Harel makes the argument that NSB was too pessimistic, and that the problems, if viewed in another light, aren’t as bad as they are made out to be. • Skepticism is not pessimism. • NSB undertakes to establish that “the very nature of software makes it unlikely that there will ever be any silver bullets.”

“Gloom” Themes • Harel perceives gloom in NSB to arise from three themes: • Sharp separation into essence and accident. • Treatment of each silver bullet candidate in isolation • Predicting for only 10 years instead of a longer time

First point • Sharp separation into essence and accident. • --That was the whole point of NSB. Seperation is absolutely central to understanding why software is hard.

Second point • Treatment of each silver bullet candidate in isolation • --The whole point of NSB is that there is no “single, magic bullet to slay the demons”. Of course he examined each candidate in isolation, that was the purpose of the paper.

Third Point • Predicting for only 10 years instead of a longer time • --10 years was a reasonable length of time, for example, because on a length of 40 years it would be reasonable to expect an order-of-magnitude improvement to productivity.

Harel’s thought experiment • Harel attempts to use reducto ad absurdum to prove his point by stating a thought experiment. • Move the date of NSB to 1952 instead of 1986 and see if it still holds true. • It doesn’t hold true as NSB begins by asserting that the accidental difficulties grossly dominated the essential ones in 1950.

The Vaporware theory • Harel goes to offer his own Silver bullet in the form of a modeling technique called “The Vanilla Framework”. The Author had not looked at the actual proposed framework, but sincerely hoped it was a silver bullet.

Invisibility • Both the Author and Harel are in agreement that one needs multiple diagrams to view a software project, each covering a distinct aspect, and that some aspects don’t diagram well at all.

Jones’s point • Productivity follows Quality. • Costly and late projects invest most of the extra work and time in finding and repairing errors in specification, in design, in implementation. • There is a strong correlation between lack of systematic quality controls and schedule disasters.

Jones’s point • He also points out that productivity drops sharply again when pursuing extreme quality, such as in IBM’s space shuttle software.

Improvements to Productivity • Many Management Information Systems are now available and do not require a custom in-house production. • Examples today would be Microsoft Office, Git and Subversion, and Microsoft Exchange

Improvements to productivity • Frees up the programmers to focus on other tasks without re-inventing the wheel.

Object Oriented Programming • There is no Silver Bullet, but perhaps a Brass one? • Object oriented programming, with modularity, encapsulation, inheritance, and abstract data-typing seems to offer a strong solution.

Object Oriented Programming • Back in 1999, OOP had not really taken off, and thus the author ponders why. • He speculates that it’s due to the heavy development in the beginning of the project necessary for OOP to work, with promised benefits later in the development.

OOP • He also argues that OOP is inherently difficult, and that it would cost corporations money to have their programmers retrained, thus perhaps slowing it’s adoption.

Argument for OOP • The author acknowledges one of the strongest uses of OOP, the ability to reuse properly constructed objects in various projects. • This “Code Reuse” is key to selling OOP to the management, as it demands higher up-front cost, but cuts costs later on in development.

Net on Bullets • And so we come back to the fundamental issue of SE. • Complexity is the business we are in, and complexity is what limits us the most.

"No Silver Bullet" Refired