Engineering May 2026 7 min read The Analogy Engine

The Chef's Knife Problem

My chef friends switch knives seamlessly. At home, I use the smallest one for almost everything. The same comfort-over-correctness pattern is running inside your tech stack... and it is quietly consuming your margins.

I have a few friends who are professional chefs. When I visit their kitchens, I notice something that I never do at home: they switch knives constantly. A different blade for deboning, another for slicing, a small paring knife for detail work, a heavy cleaver for something that needs weight. The transitions are seamless; automatic, almost instinctive. They do not think about it. They reach for the right knife the way a programmer reaches for the right function.

At home, we have the full set. Six knives; different sizes, different shapes. I use the smallest one for almost everything. My wife uses the largest. We each picked the knife we were most comfortable with and never switched. The other four are very clean because they are almost never touched.

I saw this same dynamic playing out in a small kitchen in Pune last year. I sat there for three hours watching a head cook prepare meals for 450 people using a single, slightly bent Rs 150 knife, while a brand new set of German steel blades sat in a locked glass cabinet because the owner lost the key.

The reason is simple: comfort. The chef was trained to use each knife for its purpose. We were not. We defaulted to what felt natural; and that default stuck.

Now replace "knives" with "technologies." The same pattern is running inside most engineering organisations. And it is much more expensive than a slightly inefficient vegetable chop.

I am not sure why I still think about this. Maybe it does not matter.

A tech stack built around comfort is not an engineering decision. It is a training decision. Specifically; the training, or lack of it, of whoever led the team that built it.

My friend and I have been doing deep integrations with several customer systems recently. What we keep finding is infrastructure dominated by one language, one paradigm, and a completely random assortment of tools that someone read about on a blog once... applied to every problem regardless of whether those tools are actually suited to it. Here is what that looks like in practice:

What the task needed

What was actually used

Simple relational dataMySQL or PostgreSQL... lean, fast, cheap, entirely sufficient

Over-engineered databaseA distributed, horizontally-scalable, enterprise-licensed system for a dataset that fits in a spreadsheet10x the cost

Lightweight caching layerRedis... in-memory, simple, handles millions of reads per second with minimal overhead

Kafka deployed as a cacheA distributed event streaming platform built for high-throughput pipelines, used to cache small API responsesWrong tool entirely

Periodic batch jobA simple cron script or scheduled function... runs, completes, costs almost nothing

Containerised microserviceAlways-on, auto-scaling, monitored, with dedicated DevOps overhead for a job that runs twice a dayUnnecessary complexity

The result: infrastructure and API costs so high they are consuming the entire profit margin of the business. Not because the technology is bad; because the wrong knife was used for the job.

A small paring knife and a large cleaver on a cutting board next to a cherry tomato — The cleaver will not kill the tomato cleanly. You do not need a cannon to hunt a chicken.

Wait ... I am getting ahead of myself.

Why does this happen? There are two specific reasons; and both are structural, not accidental.

Reason One

Tech teams are built top-down

Teams form predominantly around the capabilities and comfort of whoever leads them. If the engineering leader is deeply fluent in one language or paradigm, the team inherits that fluency... and that blind spot. The leader reaches for the knife they know; and trains the team to do the same. The other knives remain untouched; not because they are not needed, but because nobody learned to use them with confidence.

Reason Two

The CTO hat has no CFO component

This may be an unpopular observation, but it is accurate. The CTO and CFO roles are structurally very disjoint. A CFO or CEO typically cannot question a CTO on infra costs with any depth... they do not have the vocabulary for it, and the CTO knows it. As a result, technology cost decisions are made almost entirely inside the engineering function; without the financial scrutiny that would be applied to any other equivalent line item. Nobody asks the right questions because nobody outside engineering can ask them.

The fix is not complex. Before implementing any technology, every engineer... every one of them, from graduate to principal... should ask two questions:

The two questions that change everything

1 Is this the best technology, language, or tool that is actually suited for this specific task?

2 Is this the most cost-effective option... without compromising on quality?

Unpopular Opinion

Tech teams need approximately one hour per year on technology costs. Just one hour. Not a finance seminar; a practical session on what the tools they use actually cost at scale, what the cheaper alternatives are, and when over-engineering starts eating the business. This would not make developers less technical. It would make them significantly better engineers... because a great engineer is not someone who can implement the most sophisticated solution. It is someone who can identify the simplest one that works.

There is a saying in Hindi that I keep coming back to when I see this pattern in the field:

Hindi Proverb

"Murgi pe top nahin chalate"

You do not use a cannon to hunt a chicken.
First, you would not be able to kill it cleanly.
And even if you did... the chicken would not be edible.

The chef does not reach for the cleaver when the tomato needs slicing. The skill is not in knowing how to use all the knives. It is in knowing which one to reach for. The same principle applies to every tool that is currently being over-applied in engineering teams across the world. :)