How To Reject The Belief On The Silver Bullet

How To Reject The Belief On The Silver Bullet

In psychology there is a concept called Absolute Thinking. It represents a common tendency to think in "black and white" terms. It happens when someone provides two alternatives to a problem that doesn't have just two alternatives. This is also known as the "Black and White Fallacy" or "False Dilemma".

It's possible to observe the effects of Absolute Thinking in politics when people generalize a religion, ethnicity or any other group under the assumption that all individuals belonging to that group are the same. Humans are very bad in dealing with complexity so we tend to simplify things under the excuse that it will be easier for us to reason about it.

It's possible to observe a similar effect happening today in software development, which is when someone considers the solutions for a problem as "black and white". In this case, the “black” part represents not using any solution at all and the "white" part represents the perfect solution for all variations of that problem, a conclusion that fails to consider all the tradeoffs. We call this the "silver bullet", a pejorative term for the perfect solution that doesn't exist.

We work in an industry full of decisions and practices that have many tradeoffs. Most of the time there's no solution that works for all cases in every context and circumstance. Each of them is unique and we need to understand them first before jumping into a conclusion. As software developers, we tend to interpret "most" as "all", "sometimes" as "always" and "some things" as "everything". It's not intentional, it's not our choice, it's who we are.

As software developers, we tend to interpret "most" as "all", "sometimes" as "always" and "some things" as "everything"

One of the most common examples of Absolute Thinking that can lead developers to the conclusion of being a "silver bullet" is the Agile Manifesto.

The Agile Manifesto was written in 2001 and essentially states a series of recommendations for software development known as the best ways to produce valuable software at the time. They represent a series of principles learned by the industry after decades of pain and suffering.

The reason why the Agile Manifesto is a good example of Absolute Thinking is that most people ignore the last paragraph:

… while there is value in the items on the right, we value the items on the left more.

— The last paragraph of the Agile Manifesto

The last paragraph is supposed to make it clear that they are not recommendations that should be followed as absolute truths. It just says that there's more value in some things over others when developing software. There are circumstances where the less valuable practices from the Agile Manifesto can have more benefits for a project than the most valuable ones.

Absolute Thinking happens when someone reads the manifesto and just ignores everything on the right side of each recommendation, assuming it is a solution for all problems. This is clearly wrong. It's the Absolute Thinking affecting our capability of absorbing recommendations efficiently.

The interpretation of the Agile Manifesto is a good example of Absolute Thinking, instead of weighing the tradeoffs of each recommendation people tend to assume they are absolute rules that can't be broken and ignore situations where they don't work

One could argue that documenting things that are not absolute have no value because it doesn't allow us to apply them in any software project easily. However, if people only documented absolute practices, then there would be no progress. Subjective and context-specific techniques are part of software development and we need to understand how to handle them.

Another benefit of documenting principles that have tradeoffs is that they help to raise the discussion, a discussion that otherwise would never exist. This way each developer and their team can experiment and find out what works and what doesn't. We will still need practical experience to really know when something should be done and when it shouldn’t.

One of the best benefits of documenting principles that have tradeoffs is that they help to raise discussion, a discussion that otherwise would never exist

Are there situations where absolute principles are valid? Douglas Crockford thinks there is. When arguing about the value of certain features in programming languages, he usually says:

If a feature is sometimes useful and sometimes dangerous and if there is a better option then always use the better option.

— Douglas Crockford

However, how do we find the better option?

In the end, we need to fallback to the tradeoffs that will rely on the circumstances of that feature. We need to analyze if the better option is really better than the one that is dangerous. If it is, then it might make sense to always use it, otherwise, if there are use cases for the dangerous one, then we can't always recommend using the alternative.

Software developers tend to think in absolute terms and that can drive us to believe in silver bullets and make wrong conclusions

We need to be careful when using “always” to document a practice because it can drive misunderstanding and make someone pretend that there are silver bullets when in reality there are none. However, there are cases where it makes sense using it, and we need to be aware even though something is documented as "always" that doesn't mean it's absolute without tradeoffs.

If there's one thing we can always do is to be smart, understand our limitations as humans and reject the assumption that anything can be a silver bullet.