notes · a classic, retold

The development abstraction layer

This is my Persian-then-English retelling of Joel Spolsky's classic essay "The Development Abstraction Layer" (2006), which I first published in Persian on LinkedIn. The argument has aged better than most of our frameworks: a developer's job is code — and the manager's job is to build the layer that hides everything else.

The newcomer

Picture a young man arriving in a new city. He doesn't look bad — some savings, friendly, sociable. He doesn't talk much about his past, but his face says he spent years at some big, soulless corporation. There's a calm, unpretentious confidence about him that lets him fit in anywhere.

With exactly these qualities he starts picking up small jobs from the project board at a café for programmers. Once it's a database for an insurance firm; once a website for a housewife; once a financial calculation engine for somebody else. He gets bored of the grunt work quickly.

A year passes. He does the math and realises his savings can stretch another year. He consults his faithful dog — a German shepherd — and decides to start a big personal project. He sits at his machine in his bright rented flat above a supermarket, installs a mountain of specialised tools, calls his friends one by one: "If I'm a bit withdrawn in the coming months, or slow to reply — know that I'm working on something great."

What brilliant code buys you

And what code! Clean. Artisanal. Bug-free. A user interface so well designed you don't notice there's an interface at all. He shows the beta to a few people at the café and they're amazed.

Encouraged, he registers a small company and waits for clients to arrive. A month later he checks the bank account: three orders. One from his mother. One from a kind person he'd met at the café. And the third he placed himself, to test the ordering system.

Month two: nothing. No orders, no income. He's stunned. At his old company, everything they built had customers — even when it wasn't special. One of his projects there had been so successful its name was everywhere. So why does nothing move now?

Months pass and things get bad. His dog — always his well-wisher — now watches him with worry. He has no energy to go out, shop, shower. Every day a little greyer. One Tuesday morning the supermarket on the corner stops giving him credit. The bank has long stopped answering the phone. Eventually his old company invites him back; with no hard feelings, they even offer a higher salary. Slowly he recovers — new clothes, returning confidence — but that gleam of hope in his eyes, the one that wanted to be master of his own destiny, doesn't quite come back.

It wasn't marketing

In his own head, the failure is obvious: marketing. Like many technical people, he believes Microsoft only made it because of great marketing — their products were never that good anyway.

But when a programmer says "marketing", they usually mean everything outside their own circle of competence — all the things building and selling software requires that they don't know how to do.

The truth is his problem was never marketing. Microsoft doesn't have extraordinary marketing either — does anyone really buy Office because of that dinosaur ad? Software is, in the end, a conversation between developer and user. But for that conversation to happen, a lot of other work has to be done: marketing, sales, public relations, office space, infrastructure, customer support, accounting, and much more.

And the programmer's actual job? Design, writing code, debugging, combining code and pushing it to the repository. That's it. The level at which a developer works is so high and so abstract that it can't, by itself, keep a business alive. Just as a professional singer cannot succeed without a producer, a concert hall, a sound team, and advertising — a programmer needs an executive layer that turns code into a real product.

The layer

Every successful software company has a small team of developers riding on top of a large supporting structure. The structure is so good it creates the illusion that code alone moves everything forward — while behind the scenes it's full of people and work.

That's why one of the most important jobs of a manager in a software team is to build an abstraction layer: the developer's entire focus stays on code, and everything else — technical and non-technical — stays out of view.

The trouble is that many new managers still carry the old model of running a company — the one from the films. The boss decides, orders roll downhill, the employee is a cog. You've met the companies that still run this way: rigid policies that shed loyal customers; services that cut in and out and make cancellation an afternoon's project; carmakers that keep changing their marketing strategy while their cars stay badly made. That model is a hundred years old. In software, we need a new one:

"If your programmer is worrying about their broken chair, or fighting with Dell support over a new machine, the layer you built is leaking."

Picture your company as a yacht. The programmers are on deck, thinking only about direction and lunch. Below deck, a professional crew turns everything: engine, ventilation, table service. "Your job is to build that below-deck crew so good that nobody even notices it exists. That is management."

Two failure modes

Some companies are too sales-driven; some too technology-driven. The sales-driven ones only care about signing the contract and shipping version 1.0 — then they drop the work. The technology-driven ones get so deep into code they forget why they're building software at all — and the project gets lost in a big rewrite in Ruby or whatever framework is fashionable this month.

"The successful company is the one that puts the programmer in the middle, with a strong support system behind them that takes the code and delivers a real product."

For a developer, the ideal environment is a quiet room, a strong machine, free drinks, the right temperature, a comfortable chair — and a team that does everything else, from systems management and testing to design, sales, and support.

A curious detail: in the ancient Roman army, every soldier had about four people supporting him. In the modern American army the ratio is around seven to one. So if in your company only twenty percent of the people are programmers and the rest support them — that is not a bad thing at all. (And if you're thinking of offshoring to halve your costs, the realistic saving is closer to ten percent — rarely worth the trouble.)

"The important thing is to create the illusion of total focus on code for your programmers. Everything solved; only coding left. Don't expect them to also understand accounting or do marketing. Expecting that is like teaching a pig to sing — it wastes your time and annoys the pig."

Microsoft has built this layer so well that when some of its former employees try to start their own businesses, they fail — because they never knew what was being done for them behind the scenes.

The song you hear

In the end: when a beautiful Dolly Parton song plays on your phone, an enormous world stands behind it — studio, distribution, advertising, sales, legal. But because the system works so well, you just hear the song and enjoy it.

Original essay: Joel Spolsky, "The Development Abstraction Layer", Joel on Software, 2006. This is a retelling with credit, first published in Persian on LinkedIn, translated to English here.