How many times in your software development career have you heard the following quote?
If the only tool you have is a hammer, you tend to see every problem as a nail.
Also known as The law of the instrument or golden hammer this quote by Abraham Maslow describes a cognitive bias that involves an over-reliance on a familiar tool.
In software development that hammer could be anything you are accustomed to: a design pattern (Factories and Strategies anyone?) a language ( writing lots of NodeJs code when a tiny shell script would do the job), a framework ( React + Redux even for the tiniest simple web page), or architecture approach ( API Gateway + Lambda vs Containerized application with Load Balancers).
One solution to rule them all
Briefly, the law of the instrument means that we often tend to over-rely on a familiar tool, in fact, as soon as I hear someone speaking about an API/microservice, my first thought is:
well, easy! let's use APIGateway and a Lambda written in NodeJs, eventually add SQS and DynamoDB if we need queuing or persistence, done!.
That might be the right solution, especially for an MVP; but it could prove very wrong under some circumstances.
This cognitive bias could be very dangerous in problem solving.
At the very least it is just a big constraint to our creativity, but it could lead us to major problems like completely wrong approaches to the problem or over-engineered implementations just because, well, we really struggle to drive that screw in with our hammer.
(many years ago, I had a colleague that, for fun, on a pet project, decided to use every single design pattern he recently studied. Believe me, it was not fun in any way, the code was terribly - and of course unnecessarily - complicated.)
Recently I read this quote that summarises very well this concept (sorry I could not track back the source):
Fall in love with the problem, not the solution
Sometimes it is not just a simple bias of being used to a certain tool, which makes us see it apt for any job. Sometimes ( consciously or not) we are so in love with a solution that we really want to apply it for any problem that comes at hand (again, we could be taking about the Decorator Pattern, Docker or Blockchain, it doesn't matter).
The thing is, no matter what problem you have to solve, you think you know already the answer:
Oh, yes... that is definitely the case for XY!!
Bias, bias everywhere
The way we perceive, see, and make sense of the world that surrounds us and inside us is strongly influenced by biases, and our problem solving skills are impacted too.
Just a few examples. ( You can see an interactive map here)
- Confirmation Bias : the tendency to search for, interpret, favour, and recall information that confirms or supports what we already know and believe.
- Occam's Razor bias : the simplest explanation is usually the best one.
- Attentional Bias : individual's failure to consider alternative possibilities when occupied with an existing train of thought.
The law of the instrument is just another one, a mix of many, if we like. We like a solution, we invested time in learning and understanding some tech-stack, we are conservative, or tend to favour shiny new things, we google and read only blogs that share our point of view and so on. It is perfectly natural that our creativity in problem solving ends up constrained and bias. So what can we do?
Well. like for any other bias:
- Be aware of it
- Try to resist and challenge it.
The analysis of the requirement, and the process of problem solving should not stop immediately just because you already have a solution in mind.
Keep asking questions, keep digging.
Do not rush. Always come up with a 2 or 3 alternatives, so that you can at least compare them and present them to other people ( which may have different bias than yours):
This one is over-engineered, this is not scalable, this is scalable and simple but too expensive, this is the quickest.
Put extra effort to become your own devil's advocate.
If you have many options, you ( and the stakeholders) can make an educated choice.
We are paid to solve problems not to write code.
Of course we mostly solve problems by writing code, but that is not the point per se.
We are not paid by how much code or how long we write code ( hopefully your company does not rate your performance in LOC) therefore it does not matter if you wrote a super cool designed strategy pattern, or if you wrote a very complex, perfectly unit tested, algorithm. Maybe it was not even necessary, had you tackled the problem from another angle.
Or maybe it could have made more sense to buy a ready made solution instead of implementing it in-house.
Is that really a problem?
Another important aspect I'd like to touch is that we must learn to love problems.
Many people feel stressed as soon a problem arise.
They get anxious, feel overwhelmed by obstacles.
But, unless there are other factors like impending deadlines and a very unhealthy team mood, it is often a matter of perception and perspective.
Try to reframe what a problem is:
A bug?
A need that has to be fulfilled?
As much in my early days as developer I hated my Project Managers telling :
There are no problems, only challenges.
I really stopped to see problems ( bugs or requirements) like annoying obstacles to my happy and relaxed working day, rather as challenging tasks which indeed make my working days always interesting and fun.
And I started to love the quote "GOOD!" from Jocko Willink:
Unexpected problems? Good! it means we have the opportunity to figure out a solution.
I love problems - I do boulder!
I love climbing and bouldering. In bouldering the routes - basically the way, the path you want to climb - are called problems.
Think of it like that:
You are there, facing a wall ( or if outdoor a block of stone - literally a Boulder), and you ask yourself:
How do I climb that?
That is your problem. And you have to find a solution.
How do you use your body, your balance, your strength, how do you take advantage of every hold, grip, texture in the surface to finally get to the top?
This sport has taught me so much about myself, my strengths and weaknesses, and about looking at difficulties and finding ways to overcome them that it had inevitably an impact in my problem solving skills in my life and in my job. I will definitely dedicate a separate post about it.
Recap
stop and think, don't rush into quick solutions.
avoid the temptation to settle to general, known and safe approaches.
understand the problem first, understand the context. are we trying to solve the right problem?
We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem. Russel Ackoff
Of course I am not stating in any way that you should not be happy with the solutions you come up with, and even be proud of yourself when you solve a problem brilliantly, on the contrary, give yourself and your team all the recognition you deserve, but just be aware of the trap and don't be tempted next time you have a (similar) problem to default to the same solution.
Photo by Konstantin Evdokimov on Unsplash
Oldest comments (10)
good article, this is probably 80 percent of solving anything. Understanding what the problem is.
Thanks for sharing
Great article! Good perspectives to see a problem. See a problem like a challenge, it help us to thinking the problem is like a game, that we have to solve it and jump to next level. Thanks Davide to share you thoughts.
A great article.
How do you think this correlates with the strategy of some companies to standardize tooling? By standardizing tooling it makes it easier to handle personnel migrations (switching teams) and to get additional eyes on a problem. If everyone speaks the same languages per se then it's easier to get additional support from more people. Solutions are also easier to maintain because in theory all people know fewer solutions that fulfill more problems.
I'm interested in hearing both support for and against such a strategy.
This is a very interesting question. And I will throw my Senior Engineer / Solutions Architect wild card here: It depends. 😅
I am not a fan of Tech Zoos, having worked in many company, and in many different teams within the same company, it is never so nice, having to understand and learn new tools and frameworks everytime you switch team or project. Here Trello, there Jira, here React, there Vue, here Laravel there Symphony, here Jenkins, there GitlabCI, here Jest there AVA. The list can go on with whatever IDE, Test Framework, CI solution, MVC framework, and of course language, here node, there python, or java or php.
Of course it can be more efficient, productive and practical for a company to enforce some specific tools or frameworks, on the other end, it is also this diversity which make our job intersting and challenging. and that does not constraint our creativity and I would not like a workplace where everything is set in stone.
What i mean in the post is not constantly hopping from one solution/tool to another, rather, constantly evaluating if our choice are "automatic" and lazy or really make sense. (often it is not about choosing Svelte or React, but maybe not using any of them, about avoiding a complex setup for ECS when a tiny apigatewy would do the job.)
Of course general guidelines from CTO are important - why evaluating for every project if using AWS or Google as cloud providers, or why considering GO if there are no resources in the company knowing that language - but some flexibility is important.
Some really good tips here for knowledge workers in general, not just developers/engineers. Questioning my bias has given me the best results to my career, because it let me grow where previously I'd have ignores an avenue.
I also come back to "is it a bug, or is it a feature?". Sometimes features are just not inclusive enough, they represent a past bias expressed somewhen else. Then by questioning what was actually expected... Sometimes we can come up with a very different solution, instead of compounding and confusing the bias further.
I love this. Trying my best everyday to remind myself that challenges are good. Don't let them stress you out. They're going to come regardless!
That's actually the most dangerous bias. More code is more maintenance, more bugs, more ways to pick the wrong approach. Solutions that reuse other people's code and especially to remove code are harder to take into consideration, because it is counter intuitive - like you're not doing your job.
Some common examples:
absolutely agree and like the points you listed!
it really sums up the idea of Negative Coding - ending your day pushing your changes to the repo, with less lines of code than before. if you found a better solution with less code, if you had opportuinty to simplify and remove clutter, you probably did a good job. even if it seems you didnt do much! :-)