notes · the Mr. Sarang series

The wild horse

Mr. Sarang has sold ice cream from the same shop for fifty years. He is a little deaf, wears a hearing aid turned deliberately low, and two pairs of glasses. He is also where this series on engineering principles begins — with a joke about steam engines and a question nobody in our industry answers carefully enough: is AI a purpose, or an instrument?

An ice-cream shop, and a joke about steam engines

It was early summer, and I was walking past Mr. Sarang's shop. As usual I raised a hand in greeting. He smiled, gestured for me to come in — I guessed he had found a new topic to talk about. He always has.

I wasn't in the mood for a lecture, so I teased him instead: "Haven't you heard? The steam engine has been invented!"

A cold silence. He looked at me very seriously over the top of his glasses, then waved a hand: My boy, apparently your watch isn't wound — you're a century or two behind. Thank God we're not from those days, or we'd be sitting here talking about the steam engine. Then, with a smirk: Instead, AI is the talk of every gathering now. From marriage proposals to work meetings.

He was right, and I knew it. AI has become "purpose" number one — something everyone wants to talk about, or use, at any price. Then he set his famous traditional ice cream in front of me and said, matter-of-factly: You have to admit it — we're living in the age of steam engines ourselves. We still haven't learned that AI must not be the "purpose". It's just a tool.

A broken compass still points somewhere

He asked me: Do you know what the world looked like before people learned to tame wild horses? I didn't. He answered his own question:

A wild horse, with nobody to tame it, only knows one thing: running.

The sentence stayed with me on the way home. And so did the second one, delivered while my ice cream was quietly melting: A broken compass also shows a direction. Whether you trust it is up to you.

Steam engines, telegraphs, and ice cream

The steam engine, the telegraph, the internet, the mobile phone — each was a revolution. But none of them was ever the "purpose" at the moment it appeared:

It sounds obvious. So why does every revolution need about a decade before we stop repeating the previous revolution's mistakes? I thought about Mr. Sarang's shop — the old refrigerator, the tables, all the things that have barely changed in years — and the ice cream that tastes exactly like the day it first did. When people argue about the best ice cream in town, they point at his shop.

I wondered: if his focus all these years had been on upgrading his tools instead of the quality of the ice cream, where would the business be? And then I compared it with our world: That new server-management tool is out — let's try it. That new database is out — if we don't migrate, we'll fall behind. That architecture is out — Google and Microsoft work that way. A thousand decisions made without asking what the choice actually does to the business.

Mr. Sarang says that in fifty years, every time a new tool arrived, the first question he asked himself was: How does this help me make ice cream faster and easier? And often, faster wasn't even the answer — he couldn't sell or keep that much product. What he needed was to make exactly what his customers already wanted, better.

Before you ride, know the horse

His ancestors, he told me, were from the Lur people of the Zagros mountains — hunters and horsemen. A wild horse is a dangerous animal, he said, but tamed, it becomes the most powerful companion a human can have.

Taming means understanding: knowing when the horse gets angry, when to push and when to let go, which routes frighten it and which make it feel safe. Anyone who wants to ride a wild horse without knowing these things is in for a bad afternoon.

Three thousand years ago, his ancestors understood this. It is the lesson we software engineers and businesses forgot in our excitement to mount the AI horse. We climbed on without knowing the horse. The speed is high — very high. But the question is not how fast it goes. The question is: where is it going, at that speed?

AI speeds up the wrong process too

Years on, AI is still the star of every meeting — new models, new skills, new tools. The purpose of using the "revolution" gets far less attention.

As Mr. Sarang puts it: A fast tool makes bad ice cream faster, and good ice cream faster. It has no effect on the taste. You find out when you eat it — and by then it's too late.

There's a good line in the book Rework: good marketing just destroys a bad product faster. The main issue, then, is neither the tool nor the speed. It is who is holding the tool, and what principles they carry. Principles — the foundations that determine the output regardless of the tool. That is exactly what this series is about: not new ideas, but the ones we already know, re-examined through Mr. Sarang's lens.

Why ice cream?

You might ask why ice cream — what it has to do with engineering and business. Mr. Sarang's answer: Because ice cream goes off. If you write bad code, you keep building on it tomorrow. If you make bad ice cream, the customer never comes back. Both mistakes have a cost — but he feels his, because when the milk spoils, it smells. You don't see bad code that easily. You think you do. At the end of the month there's a server invoice, and a sprint carried over to the next sprint.

An ice-cream shop is an almost perfect model for understanding business fundamentals, because its constraints are tangible: perishable raw material, a bounded season, thin margins, and every mistake felt directly in the shopkeeper's pocket. In software, all those constraints exist too — we just prefer to forget them. The cloud looks infinite. Code never rots (it only gets deprecated). Mistakes show up months later on an invoice, not today, as the smell of sour milk.

The roadmap

The Mr. Sarang series is planned as nine chapters and twenty-six parts. Each part takes one fundamental idea of software engineering and product management and tells it through Mr. Sarang's real stories — ideas that hold whether or not AI is in the room. With references to credible books and articles along the way.

This is for you if you're a developer and feel something is missing between the sprints and the Jira cards — something no documentation covers. If you're a tech lead and know that deployment speed alone isn't a success metric, but can't quite say so in the boardroom. If you're a product manager and fear the day you realise the technical team, at full speed, is building toward a compass instead of a destination.

Next part: the speed trap.

The wild horse of AI only knows how to run. Taming it means understanding it — and knowing where you're asking it to go.