Winter Rant

It’s not so bad afterall

The title to this post is a blatant reference to the “No Silver Bullet” paper by Brooks (1987), where he tells us how hopelessly outgunned we are at the face of four essential difficulties with software:

• software is complex
• software is highly changeable
• software does not conform to any single uniform theory
• software is invisible

And he argues quite convincingly that no matter what we do, and no matter how hard we try, these 4 difficulties cannot go away. What is most striking about the arguments in the paper is that they hold true even today, more than a quarter century later.

The problem is that we came into the world of software from the world of hardware and machines, where finely cut out solutions just worked and plans had meaning. We thought that such a regimented approach would work with software as well. It clearly did not; and so we panicked! We never realized back then, that software was finally servicing humans who have changing needs. It was not like a machine made up of metal or a house made up of brick that could not change, and forced humans to adapt. Software could change, and so it was the one made to adapt.

When we did realize that, camps began to emerge advocating different styles and approaches to building software. Some professed a regimented approach that closely resembled the styles employed in building hardware machines. Others took a more agile view of things, and said that change is best encountered by being nimble. Both such camps were wrong. Never did the idea became popular, that just as software needs to resemble human needs, the strategies to develop software had to resemble the social dynamics that humans had. A regimented approach would perhaps work best while developing software for disciplined folks; and so with the agile approach. A mismatch between a process to develop software and the underlying social dynamics of the people for whom the software is meant for, is a death-wish for the software project (Nutt, G.J. 1996. The evolution towards flexible workflow systems. Distributed Systems Engineering, 1996).

You see, Brooks probably realized that even back then. Because, despite his arguments in the Silver Bullets paper that sucked hope out of a software engineer, Brooks does give us all a glimmer of hope. He espouses notions of buying and growing software like plants and gardens, instead of building it like machines. The idea of growing software humanized the notion of software engineering (not the buying bit though). And the notion of buying software eluded to the notions of modularity, reusability and, well basically, COTS (commercial off the shelf software).

One has to take a moment and realize that today, more than even before, those ideas have taken full shape and form. Software solutions are being met not by building everything from scratch, but by assembling existing components together atop generic frameworks. The notion of “It works on my machine” is fine with the advent of virtual machines that can be replicated almost anywhere. We now talk of software ecosystems (think Android, iOS, Eclipse, HTML5) as if they were plant kingdoms. And while those four essential difficulties that Brooks highlights have not vanished, the blow has been softened.

For all the foresight Brooks had with his paper, I think what he might not have realized was that in simply pointing out the lack of a silver bullet, he probably gave us one. It is very much like “change being the only constant”. The realization that there is no silver bullet might just be the silver bullet we have been looking for; as my fellow software engineer and friend puts it — a “meta silver-bullet.”