The law of Instrument — If you have a hammer…
Do you have Microservices? Oh, why are you still using Ruby on Rails, why not Elixir? Are you using Docker or Kubernetes?
These are the usual questions I hear when I speak about the architecture of our product Good Karma. I don’t use any of the above “cool” tools because I don’t think I need to.
We are a four-member startup, includes two programmers, serving our customers. None of the above “cool” tools helps us to deliver better value to our customers, at least as of today.
We use our product to learn about our customers. So we invest our time to improve the bottlenecks in our software delivery which help us to:
- Deliver code faster and safer
- Improve Production Telemetry
And we don’t see either Microservices or Kubernetes helping us achieve any of the above as of today.
Instead, we give a lot of importance to:
- TDD, Refactoring and Clean Code
- Incremental Design and Evolutionary Architecture
- Domain Driven Design
In summary, we adopt tools or techniques to help us “delivering value continuously in a sustainable and repeatable manner”.
I have high respect for Microservices architecture, Functional Programming and Containers. All these are great because it solves specific problems which each of them focuses on.
And these are recommended solutions when you face similar problems. And it is highly recommended not to use it if you don’t have the problems that they solve. If a team can’t write modular code with Monolith, how can they be successful with Microservices? I find the following articles relevant here:
Interestingly, the Wikipedia article — about Law of Instrument — refers to how computer programming industry is affected by the law of Instrument. The article says that programmers do it to be in the comfort zone.
But I also see the other problem, let’s use all these tools because it is cool. Does it help to deliver better value to customers, who cares?
I hope one day we will learn that perfect is a moving target and there is no one size fits all.
