There's still no silver bullet

The late, great Fred Brooks wrote many words about software engineering. You may have heard of Brooks’s Law or read his seminal book, The Mythical Man-Month. Even if you haven’t, you’ve probably heard at least one colleague proclaim:

Nine women can’t make a baby in one month!

This is a powerful metaphor for two reasons. First: it’s so vivid that it’s hard to forget (and easy to recall in a time of need). Second: it makes obvious a not-so-obvious conclusion. Which is:

Adding manpower to a late software project makes it later.

That’s a hard pill to swallow, especially when your project is late. But it’s a truth pill, which makes it worth choking down. Here’s another truth pill that Brooks wrote in his paper No Silver Bullet–Essence and Accident in Software Engineering:

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.

For those who don’t understand the silver bullet reference… it’s pulled from folklore where a bullet cast from silver is the only weapon that can kill a werewolf. Over time a silver bullet has come to represent “a simple, seemingly magical, solution to a difficult problem.” Brooks could have easily reached for panacea instead, but I think the shiny characteristic of silver makes it the perfect analog to software solutions.

I’ve found myself referencing this a couple times recently. Both of those conversations were in the context of React, but the principle applies to every over-adopted technology.

So, this post is a gentle reminder to my fellow software engineers:

• Does a new tool promise to solve all your problems? It won’t
• Do you think you’ve found the “one true tech”? You haven’t
• Have a shiny hammer that looks great for hitting screws? It isn’t

Please humor me while I quote myself for a moment: (Hey, it’s easier than writing)

We tend to be kind of lazy and just take the big hammer and hit all the nails with it. Like, “Oh, I’ve found the panacea. This is gonna solve all my problems”, because it does solve some of your problems big-time.

But it’s also is gonna create other problems, and it’s also not gonna fit in every place that you can shove it. I mean, I know there’s React-based command line builders… And it’s like, okay, if you like components, cool. That makes sense. But why is React building your command-line app? I just don’t understand.

When I extemporaneously said “I just don’t understand”, I meant that the choice confounds me. But I do understand why people might make it.

Saying “use the right tool for the job” is easy, but actually selecting the right tool for the job is anything but. Good tools are hard to find, hard to evaluate, hard to learn. We have constraints, we have biases, we have shortcomings.

But that’s all part of the work.

And if you “just use Go” or “just use React” or “just use Postgres” for every problem that crosses your keyboard, you’re just not putting in the work.

(And I say this as a guy who uses Postgres for most things! 😆)

If you enjoyed reading this, you’ll probably enjoy Changelog News, my free weekly podcast + newsletter covering developer news worth your attention. I keep it brief (~8 min), entertaining & always on-point. Not so sure? Check out a recent issue!