Technology. Technology always changes. But through it all there is always one tendency that remains: to overuse a tool, language or framework just because it is familiar or in some cases, trending, even though it may not be the best solution for the task at hand.
Every the screw becomes a nail
This was evident with the use of microservices, serverless architecture trend that rose over the past decade. While this approach did have its merits, it started being used everywhere, ending up in a scenario where even the champion of this architecture, Amazon, decided to dump it in favor of a monolithic approach.
As psychologist Abraham Maslow rightly stated,
“If the only tool you have is a hammer, it is tempting to treat everything as if it were a nail”
This cognitive bias, the “law of instrument” or “Maslow’s Hammer”, takes over our decision making when we become highly skilled with a particular tool or approach. This leads us to apply it even in situations where it might not be the most appropriate choice. This narrows our focus and prevents us from considering a wider range of better solutions.
While we may get efficient with using the tool, the choice may lead to an overall inefficiency in the project with poor performance and higher costs. Complexity of the project increases from forcing familiar solutions onto incompatible problems. We end accumulating technical debt, and facing scalability challenges as the project grows.
Take the microservices use-case: Kelsey Hightower, known for his work on Kubernetes, explained it well:
You know what we should do? We should break it up.
…
And then what they end up doing is creating 50 deployables, but it’s really a distributed monolith. So it’s actually the same thing, but instead of function calls and class instantiation, they’re initiating things and throwing it over a network and hoping that it comes back. And since they can’t reliably make it come back, they introduce things like Prometheus, OpenTracing, all of this stuff. I’m like, “What are you doing?!”Now you went from writing bad code to building bad infrastructure that you deploy the bad code on top of.
Stepping back and looking at the instruments we have at hand, we can come to understand the specific problems which each of them is useful to solve for. Then, if we compare it with the problem we are solving for, we can then make the right choice of the tool. Consider factors like performance, scalability, ease of maintenance, and the developer team’s experience. Sometimes, a simple language or framework will work just fine; other times, a more complex or specialized tool may be necessary.
Ideally, choose the screwdriver for the job if that is what is needed rather than the hammer, even if the screwdriver will take us more effort to acquire. In the long run, this screwdriver is what will save us time and money and help us get the job done right.
Each project comes with unique requirements, and we should evaluate these needs carefully before selecting a tool. Remember: solving the problem with the right tool is much more important than just using whatever tool we have at hand.
A special thanks to DHH for his take on Amazon’s shift from serverless and microservices.
