“I believe the hard part of building software to be the specification, design, and testing of this conceptual construct,[…] If this is true, building software will always be hard. There is inherently no silver bullet.”
Frederick P. Brooks, Jr. Computer Magazine, Apr 1987
Hat Tip To Joel
Joel Spolsky wrote an article, Lego Programming, about how mainstream media gets it wrong. And he ended the article with an interesting quote:
None of them believed Frederick P. Brooks, in 1987: “Not only are there no silver bullets now in view, the very nature of software makes it unlikely that there will be any—no inventions that will do for software productivity, reliability, and simplicity what electronics, transistors, and large-scale integration did for computer hardware[…]”
Spolsky quoting Brooks
I used to have a department manager who regularly asked for silver bullets – not metaphorically, literally. So I just had to check out Mr. Brooks’ article.
Brooks in 1987
Any article about software that still rings true after almost 20 years is amazing. Brooks starts us off right away with his conjecture that the big problem of complexity in software will never be solved. He proposes that an order of magnitude improvement might be found, but that the problem will never go away. Never? We still have the problem today.
Brooks identifies elements of the essence of software that make it forever a were-wolf (no silver bullet).
- Complexity. Brooks cites the non-linear increase in complexity of software with size of software. Even with OO constructs and abstraction layers, this is still true today. With a decade of enterprise software experience, I will vouch for this, in terms of complexity versus “size of the software.” The recent thread on Vista’s shutdown options is another good example – not because there are so many ways to do it, but rather because the team spent over a year implementing it. As to complexity vs. “value of the software”, I’m not certain it is non-linear. Applications are getting larger (generally), but the amount of value they provide is growing much faster. Not cause-and-effect, but correlating. Businesses are re-engineering to utilize software in their processes. Those savings are large, and inferring from the increases in spending on software, are more valuable than in the past. Is achieving “the same value” easier today than twenty years ago? Yes. So much so that we don’t even try to do it – we try to do harder, more valuable stuff.
- Conformity. Brooks argues that there are no guiding principles that cause software engineers to conform (stylistically, representationally, etc). Therefore, they will spend some cycles dealing with “arbitrary complexity.” Fair point.
- Changeability. Software becomes complex because it can. Brooks points out that cars don’t change often, because it isn’t easy to change them. Software has no such barrier. If you’ve ever spent time on a working farm, and seen the myriad of wonderful things that can be accomplished with bailing wire, twine, and duct tape, you know that the impetus to change things is not limited to software. Without the natural barriers enjoyed by manufactured goods, software will be changeable, and therefore hard.
- Invisibility. Brooks argues that because of the representational power of software, we represent constructs that we inherently can not visualize. Some smart physicists at Nicholas Copernicus University agree, and spend considerable effort “simplifying” multi-dimensional data into a framework we can accept.
Brooks discusses several advances in software, and approaches that people hope will be a silver bullet. He posits that none of them have been or will be (as of 1987). We’re approaching two decades later, and none of them have. There are some prescient quotes in his article.
Effective Strategies
Brooks also discusses some effective strategies to change the essence of software complexity and find a silver bullet.
1. Buy Vs. Build
He proposes a very outside-the-box solution – don’t build the software, buy it. Buying customized software is not what Brooks proposes. That would be no more effective than Kanban was (shifting the overhead burden onto suppliers who subsequently raised prices). He proposes using non-customized software, and adapting business processes to those supported by the off-the-shelf software.
2. Requirements Refinement and Rapid Prototyping
His opening paragraph is a very strong statement – and one we agree with:
The hardest single part of building a software system is deciding precisely what to build. No other part of the conceptual work is as difficult as establishing the detailed technical requirements, including all the interfaces to people, to machines, and to other software systems. No other part of the work so cripples the resulting system if done wrong. No other part is more difficult to rectify later.
Brooks goes on to make a statement that seems eerily similar to one I’ve heard Kent Beck say:
I would go a step further and assert that it is really impossible for a client, even working with a software engineer, to specify completely, precisely, and correctly the exact requirements of a modern software product before trying some versions of the product.
From this perspective, Brooks promotes incremental development as the right approach. In 1987!
3. Great Designers
We’ve always said that people trump process. Brooks said it first.
Conclusion
Software is hard. Requirements are harder. Nothing (according to Brooks) will ever change that.
