There Is No Silver Bullet in Software Development

Every programming rule I teach is wrong. And that’s exactly why you should follow it.

Every experienced developer knows the honest answer to most technical questions is “it depends.” Yet we rarely say it. Not because we’re arrogant or lazy, but because we’ve learned something paradoxical: the best way to teach “there are no silver bullets” is to hand someone a silver bullet and let them discover its limits themselves.

«There is no silver bullet in software development» — Generated and edited by the author.

My professor changed me forever with two words:

“It depends!”

Every class, he’d ask seemingly innocent questions. “Which is better, Microsoft Access or MS SQL Server?” Students would confidently declare SQL Server — obviously more powerful, more flexible, and more real. Then he’d shout those two words that would stay with us forever: “It depends!”

“Your friend’s video rental shop with 200 customers? SQL Server would be absurd. Access would be perfect.”

By semester’s end, we couldn’t answer anything without pondering deeply. We’d become paralyzed by nuance. And we loved it!

Twenty years later, I write articles about software development. I share rules, patterns, and principles. “Don’t use mocks in your tests.” “Never rewrite from scratch.” “Code coverage is a useless metric.” And a part of me wants to scream:

“It depends!”

And often I feel guilty, because it doesn’t matter how much nuance I give, every rule has more exceptions, and there are more situations than I can write or even imagine.

Yet, I finally realized that I shouldn’t.

The Hunger for Certainty

We’re all looking for the silver bullet. That one pattern, principle, or practice that will solve everything. The rule that will make the chaos manageable. The formula that will make us feel like we know what we’re doing.

And that is the process of learning.

The Dreyfus brothers understood this when they studied how people acquire skills. They identified five stages: Novice, Advanced Beginner, Competent, Proficient, and Expert. And here’s the compassionate truth: novices don’t just prefer rules — they need them to function.

A novice developer literally cannot operate without rigid guidelines. “Always write tests first.” “Never use global variables.” “Classes should be small.” These aren’t just helpful suggestions; they’re lifelines in a sea of complexity.

And when that novice takes any of the silver bullets about avoiding mocks and applies it everywhere? They’re not misunderstanding me. They’re surviving.

The Beautiful Paradox

But why do we stick to rules even when they’re flawed? Why is believing something incomplete better than acknowledging uncertainty?

Evolution has an answer, and it’s profound: Error Management Theory.

Imagine you’re walking through tall grass. Something moves. Is it a stick or a snake? If you assume every stick is a snake, you’ll jump away from a lot of sticks — embarrassing, inefficient, seemingly irrational. But if you assume every snake is a stick just once, you’re dead.

Our brains evolved to prefer useful errors over costly accuracy.

This isn’t a bug. It’s a feature.

The same principle applies to software development. When a junior developer religiously follows “no global variables ever,” they’ll occasionally make their code more complex than necessary. But that’s infinitely better than the spaghetti nightmare that awaits if they use globals incorrectly.

The rule isn’t perfect. But imperfect rules that keep you safe are better than perfect knowledge you can’t yet handle.

The Compassionate Truth

Here’s what took me too long to understand: those “wrong” applications of my rules aren’t failures — they are a necessary stage of growth.

When someone reads “don’t use mocks” and eliminates all mocks from their codebase, even where mocks make sense, they’re not being stupid. They’re being human. They’re at the stage where they need that simplicity to make progress.

As they grow (moving through the Dreyfus stages), something magical happens while leveling up:

• Competent: As soon as they get confident, developers start noticing exceptions.
• Proficient: And then, they learn when to break rules.
• Expert: So they become the teacher, and create new rules for specific contexts.

The silver bullet transforms from a survival tool into training wheels, and eventually into something you remember fondly but no longer need.

The Meta-Twist

Even “there is no silver bullet” isn’t a silver bullet.

Sometimes, universal rules do exist. “Don’t commit passwords to version control” — I challenge you to find an exception. “Back up your data” — please, prove me wrong.

But these are rare. Most of our cherished principles — DRY, SOLID, even “test everything” — have contexts where they cause more harm than good. And that’s okay. That’s not a failure of the principles. That’s the nature of navigating complexity.

Time’s up: Don’t commit passwords, unless for example is the default user and admin password that will be forced to change as soon as the user logs in for the first time. Or don’t back up your data if you need to remove something definitively.

My New Approach

I’ve stopped agonizing when anyone takes my advice too literally. For a long time I added endless caveats to every principle I shared, and I always felt that they were never enough, but I’ve stopped. Not because I’ve given up on nuance, but because I’ve gained compassion.

Is that developer applying my anti-mock advice universally? They’re exactly where they need to be. In six months, they’ll notice some tests becoming unwieldy. In a year, they’ll think, “Maybe a mock would work here.” In two years, they’ll write their own article: “When Mocks Make Sense (Despite What David Says).”

Yet, something worse can happen: “Apply Mocks Everywhere (Despite What David Says)”. Yet, no problem. After that feat they will realize how huge a mistake it was and finally will understand when to apply or not apply mocking.

And I’ll read it with a smile.

The Resolution

We don’t need to eliminate silver bullets. We need to understand them for what they are: beautiful lies that keep us safe while we grow strong enough for the truth.

Every rule I write, every principle I advocate — these aren’t eternal truths. They’re gifts to a specific version of you. The you that needs them will embrace them. The you that’s outgrown them will transcend them. Both are right.

So to my readers who treat my words as gospel: Thank you for trusting me with your learning journey. Use these rules. Abuse them. Let them constrain you until you’re ready to break free.

And to my fellow experts who see all the nuance I’m omitting: Yes, it depends. It always has. But sometimes, the most compassionate thing we can do is pretend it doesn’t.

Because in software development, like in life, we all need our silver bullets — until we don’t.

The next time someone asks me if there’s a silver bullet in software, I’ll tell them yes. And also no. And that both answers are true, depending on who’s asking and where they are in their journey.

It depends.

And that’s beautiful.

Thanks for the read. I usually like to write stories to think about how we understand and apply software engineering and to make us think about what we could improve. If you liked the article, don’t forget to clap, comment and share. For more insights and discussions, explore my most successful stories on Medium, or just check out my book where I tackle both code and coder struggles.