What we want from a Silver Bullet

In 1975, Fred Brooks published "The Mythical Man-Month", an important and well-respected essay on project management. Project management, especially for IT projects, was troubled by delays, discovered complexities, unexpected costs, and budget overruns. He observed that adding people to a late project makes the project later. That is, counter to project management techniques, increasing resources (people) reduces progress. (The reason is that an IT project is complex and requires a high level of understanding and a high level of communication. Adding people to a project adds people who are unfamiliar with the project and therefore ask a lot of questions, question a lot of ideas, and sap time and energy from the veterans of the project.)

Brooks later published a revised version in 1982 with an extra chapter entitled "No Silver Bullets". This chapter introduced the ideas of essential complexity and accidental complexity. The former is part of the task at hand, something that must be dealt with no matter which tools or techniques we use. The latter is not part of the task, but instead generated by of techniques, our tools, and the organization of our data. But most people miss (or forget) that part of the essay.

Instead, people latched on the to notion of "silver bullets". The new chapter used the metaphor of werewolves (the difficulties of managing projects) and silver bullets (the only thing that could slay a werewolf, and therefore a magical solution for project management).

While Brooks argued that there were no silver bullets, the term stuck, and so did the metaphor. We in the management of IT projects have been looking for silver bullets, tools or techniques that will tame those delays, complexities, and unexpected costs.

The metaphor is picturesque and easy to understand (two good qualities in a metaphor) but is, alas, inaccurate (not such a good quality in a metaphor).

I have a different view of projects and "silver bullets" (if I may keep the metaphor for a short time).

We don't want silver bullets, at least not in the general understanding. We think of silver bullets as better tools or better techniques. We think in terms of processors and operating systems and programming languages, of databases and web servers and cloud systems.

But better processors and better operating systems and better programming languages are not silver bullets. In the forty years since Brooks wrote "No Silver Bullets", we have seen faster and more powerful processors, better languages, new approaches to data storage, the web, and cloud computing. Yet our projects still suffer from delays, unexpected complexity, and budget overruns.

But my point is not to say that Fred Brooks got it wrong (he didn't, in my opinion) or that his readers focus on the wrong point from his essay (they do, also in my opinion), or that we are wasting time in looking for a silver bullet to kill the problems of project management (we are, foolishly).

No, my point is something different. My point is that we don't really want better processors and programming languages -- at least not in the normal sense.

I think we want something else. I think we want something completely different.

What we want is not a thing, not a positive. We don't want a "better X" just to have a better X. Instead, we want to eliminate something. We want a negation.

We want to eliminate regrets.

We want tools that let us make decisions and also guarantee that we will not regret those decisions.

The challenges of IT projects are almost entirely regrets in choices that we previously made. We regret the time it takes us to write a system in a certain programming language. Or we regret that the programming framework we selected does not allow for certain operations. Or, after building a minimal version of our system we are disappointed with the performance.

We regret the defects that were written into the system. We regret the design of our database. We regret outsourcing part of the project to a team in a different country, in a different culture and a different time zone.

The silver bullet that we want is something that will eliminate those regrets.

We look to no-code programming tools, thinking that we no code we will have, well, no code to debug or modify. (Technically that is true, but the configuration files for the no-code platform have to be revised and adjusted and one can consider that programming in an obscure, non-Turing-complete language.)

We look to NoSQL databases to avoid regrets of database design and complex SQL queries. I'm sure that many people, in 1999, regretted the decision that they (or earlier members of their teams) had made about storing year values in 2-digit form.

But in system architecture, in database design, in programming, there is no avoiding decisions. Every activity involves decisions, and recording those decisions in a form that the computer can use.

Instead of a Silver Bullet, people are looking for the Holy Grail, an object that can erase the consequences of decisions.

I will point out that the Agile Development method has helped reduce regrets. Not by preventing them, nor by erasing decisions, but instead by letting us quickly see the consequences of our decisions, when a change to those decisions is easy to implement.

Tools such as programming languages and version control systems and data storage systems help us build systems. The tools that let us be most effective are the ones that let us see the results of our decisions quickly.