TL;DR: 25+ years after it was written “No Silver Bullet” by Fred Brooks still delivers an extremely relevant framework for thinking about software development but don’t take my word for it but read it
I would like to say that I have read No Silver Bullet by Fred Brooks some 20 years ago. Or at least 10. But I can’t. I read it for the first time last week followed immediately by “‘No Silver Bullet’ Refired”.
I don’t know why it took me so long. I sure have read a huge amount of irrelevant or inferior content. I think that it was a context in which I first heard about it and in which it was mentioned, discussed and used for several years - as no methodology is the silver bullet hence no silver bullets. I never felt that I needed to read anything toward that particular conclusion especially since back then (year 1999 or 2000) I was working in a company that was trying to implement Rational Unified Process of all things. But I was very naive and extremely opinionated back then so that on its own should also be taken with an overdose of salt.
Anyway, I wasn’t planning on reading No Silver Bullet this week either, until I went to read Wikipedia’s article on it, just to understand it on a general level (though I can’t say now what prompted me to do so). And what I read there surprised me:
Brooks argues that “there is no single development, in either technology or management technique, which by itself promises even one order of magnitude [tenfold] improvement within a decade in productivity, in reliability, in simplicity.” He also states that “we cannot expect ever to see two-fold gains every two years” in software development, like there is in hardware development.
Wait… what? It’s not essentially about methodologies? There was more:
Brooks makes a distinction between accidental complexity and essential complexity, and asserts that most of what software engineers now do is devoted to the essential, so shrinking all the accidental activities to zero will not give an order-of-magnitude improvement.
As soon as I read the above quote, I knew that I had to read it. So I fired up my Safari To Go app and started reading The Mythical Man-Month which includes the No Silver Bullet essay (to make the irony of all this even stronger - I have a printed copy of that book somewhere around the house and I have had it for the past 10 years.)
So is it any good? It’s great. Here’s what Brooks himself writes as the essence of the article (which is by the way not only great content but great writing):
Therefore it appears that the time has come to address the essential parts of the software task, those concerned with fashioning abstract conceptual structures of great complexity. I suggest:
- Exploiting the mass market to avoid constructing what can be bought.
- Using rapid prototyping as part of a planned iteration in establishing software requirements.
- Growing software organically, adding more and more function to systems as they are run, used, and tested.
- Identifying and developing the great conceptual designers of the rising generation.
Let me revisit today, more than 25 years after the original essay, on how I’m faring when it comes to these recommendations.
Exploiting the mass market or “Buy versus build”
This is where I would say that I fare very well. In the past several years the biggest luxury that I’ve given myself in this regard is assembling this site and even then I didn’t do it from scratch. But I didn’t hire anyone to do it so in that one sense I built it. This was intentional and I like it that way but even then I first evaluated a pretty known commercial alternative for site building and found it less than compelling.
Anyway, consider the larger picture of development world today in general. I have mostly done system programming in my career mixed with application programming and quite a lot of database programming for good measure. In all these areas today we build on top of already available frameworks and even though many times we don’t buy them, we sure as hell don’t build them!
Brooks writes:
The development of the mass market is, I believe, the most profound long-run trend in software engineering. The cost of software has always been development cost, not replication cost. Sharing that cost among even a few users radically cuts the per-user cost.
What Brooks couldn’t know is that the paradigm of free and open source software (FOSS) would gain huge momentum since then. I have spent my career (so far) working on proprietary platforms but that’s more by chance than by design. But even then I have extensively used open source software and it has often been critical for success of my projects. For example, the knowledge of Boost library is something that I require from C++ hires.
“Standing on the shoulder of giants” has become a cliché (and certainly Brooks is one of those giants) but today any developer can choose to stand on the shoulders of many other developers, some giants, most not, that have poured countless hours of love, passion, dedication and ability to create and maintain FOSS. But Brook’s larger point stands and that today the are so many things that are truly free and open to reuse, leverage, expand is so much for the better.
Rapid Prototyping
Unlike the previous point which I think has been thoroughly adopted in our industry (in many ways just as Brooks imagined but also heavily through FOSS), I can’t judge if rapid prototyping is as well established. I would guess so but considering how many projects fail (I have heard statistics of one third of projects failing) I would guess that there is room for wider acceptance.
Brooks writes:
Complex software systems are, moreover, things that act, that move, that work. The dynamics of that action are hard to imagine. So in planning any software activity, it is necessary to allow for an extensive iteration between the client and the designer as part of the system definition.
Me personally, I already wrote about it. I build software, as developer and/or PO, by “drilling” to first functional version and then expanding it (growing it as Brooks later writes) in what appears to me to be the most optimal direction. But the feedback from the prototypes is critical for this.
There is just one danger with prototyping and that is the tendency of some developers to treat prototyping code as something that can be badly written, badly named, badly commented and then simply adopted into production code. I don’t tolerate this in my work or work of others as I strongly feel that it’s a slippery slope toward worse software.
Brooks finishes this section with:
Much of present-day software acquisition procedures 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.
I wonder how many countless mega-years of have been lost in human productivity and wellbeing by falling into that particular trap.
Incremental development
Brooks writes:
Some years ago Harlan Mills proposed that any software system should be grown by incremental development.[11] That is, the system should first be made to run, even though it does nothing useful except call the proper set of dummy subprograms.
This ties directly into the previous point of rapid prototyping and to what I (again) wrote in Product Development as Drilling. The initial prototype is the sprout (not the seed) from which the future product will be grown. Doing it any other way but growing the software incrementally is thinking, contrary to all the experience that we have, that even modestly complex software can be built perfectly the first time. But it’s not only that. Brooks continues:
I have seen the most dramatic results since I began urging this technique on the project builders in my software engineering laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.
I couldn’t agree more and again I recently touched on the subject in Elastic Software Development:
This is incredibly useful conceptualization of what makes the software development process actually flow, at least in my experience. There are bound to be bugs in the specification itself and we have to discover them and fix them during the development (acceptance over specification). We stick to the timing of the development plan, cutting whatever can be cut to make it (progress over completion). Circumstances will change, new knowledge will be acquired, more mature ideas will occur to us and we have to be able to deal with them as they are presented (reactivity over commitment).
I do start from specifications as that gives me the overall feel, the shape of the future product and the first chance to think about what we are actually trying to build. But I axiomatically treat the specifications as buggy and incomplete. When starting to develop, the specs have to be relentlessly developed into a first functioning prototype which we can then grow the product, feeding the experience of the growth into specifications and trying to find the most optimal solution in the problem space we have (which includes the time we have to actually build the product).
Brooks immediately continues:
The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system.
This is why I got hooked on programming in the first place! I wont go so far as to call it instant gratification but it sure feels like a powerful jolt into the brain when the act of creation and the act of witnessing the effects of the creation are so close to each other (okay, okay, let’s call it instant gratification)
Great designers
Brooks writes (his emphasis):
Whereas the difference between poor conceptual designs and good ones may lie in the soundness of design method, the difference between good designs and great ones surely does not. Great designs come from great designers. Software construction is a creative process. Sound methodology can empower and liberate the creative mind; it cannot enflame or inspire the drudge.
And he concludes:
My first proposal is that each software organization must determine and proclaim that great designers are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded.
I think that developers cannot expect this coming into a job but they can prove their worth, grow business value and show what they got on almost any job. And for my part I have tried to create good conditions for software designers that work with me so that they can develop and help me develop (not only software, but ourselves). And I have striven to make room for them and room not only for great ideas and implementations but also for experimentation, making errors and fixing the same. Which reminds me of this quote by Ed Catmull:
The notion that you’re trying to control the process and prevent error screws things up. We all know the saying it’s better to ask for forgiveness than permission. And everyone knows that, but I Think there is a corollary: if everyone is trying to prevent error, it screws things up. It’s better to fix problems than to prevent them. And the natural tendency for managers is to try and prevent error and over plan things.
We often put junior developers into conceptual sandboxes, keeping them away from “important parts” and stunting their growth. I prefer to work with developers that always want enough rope to hang themselves and that are always on my case for more responsibility. I cannot control everything so the only way forward is to build a culture of trust and responsibility and live in it daily. This is how you grow and keep around the people you want to work with.
Conclusion
I think that I can’t make a better conclusion that my “TL;DR” lead:
25+ years after it was written “No Silver Bullet” by Fred Brooks still delivers an extremely relevant framework for thinking about software development
At the end “No Silver Bullet” was not about methodologies, processes, technologies and not even about great designers. It’s about thinking about how to make useful, innovative, “value generating” and timely software in the real world.
That said I have to say that this post cannot do it justice and that you really should read the whole thing as there is so much more in it than what I mentioned. Brooks doesn’t just make claims, he works his way through why he is making them and what are the alternatives. It’s a great essay and I’m really happy to have finally read it.
Last modified on 2013-06-01