Parkinson's Law Eats Silver Bullets

In his essay No Silver Bullet: Essence and Accidents of Software Engineering, Fred Brooks makes the following postulate:

There is no single development, in either technology or in management technique, that by itself promises even one order-of-magnitude improvement in productivity, in reliability, in simplicity.

This “law” was recently invoked by Joel Spolsky in his post Lego Blocks, which prompted an interesting rebuttal by Wesner Moise.

That assertion turns out to be pure nonsense, amply disproven by numerous advances in IDEs, languages, frameworks, componentization over the past few decades. Our expectations of software and our ability have risen. A year of work takes a month or a month of work takes a day.

Whether you agree with Wesner’s position or not comes down to how you define a single development.  It could be argued that the order of magnitude improvement we have now is a cumulative result of multiple improvements.

Regardless, perhaps a more lasting way to rephrase this assertion is to state that no single technology, development, or management technique will produce by itself an order-of magnitude improvement in meeting current business needs.

In other words, sure we can produce an order-of-magnitude more productivity now than we could before, but changing business climates and consumer needs have also increased by an order-of-magnitude. Just compare a modern game like Oblivion to an older game like Ultima I.

In a way, this is Parkinson’s Law at work:

work expands so as to fill the time available for its completion.

I’ll restate it to apply to software engineering:

Business needs and feature requirements increase to fill in the productivity gains due to silver bullets.

What do you think, is that sufficiently original to call it Haack’s Law?

In any case, I think Joel’s original point still stands. Building software to meet current needs, will always be hard.  When you think about it, the dreams of building software with lego-like blocks has been realized. But only for those who need to write software that meets the needs of users in the 1960s.  For modern needs, it remains challenging.