The long view

Software for decades, not quarters

You cannot build software for the long term inside a business built for the short one. The code can be as durable as you like, but if the company around it needs a bigger number every ninety days, that need will win every argument in the end — and the software will be bent to serve the quarter, whatever the engineers intended. Longevity is a business decision before it is a technical one.

The quarter is the enemy of the decade

A quarterly target is a small, relentless force, and over years it reshapes everything it touches. It rewards the change that shows up in this period's numbers and punishes the patient work that pays off later. It makes the pivot rational, the acquisition attractive, the corner worth cutting — not because anyone is short-sighted, but because the structure keeps asking the same question, and what helps the decade is rarely the answer that also helps the quarter.

This is why so much software that started with good intentions ends up somewhere else. The intentions were real; they were just outvoted, ninety days at a time, by a structure that could only see ninety days ahead. You cannot out-will an incentive that reasserts itself every quarter. If you want software that serves the decade, you have to remove the thing that keeps pulling it back to the quarter.

The shape that removes the pressure

So the long view is, before anything else, a company shape. No board demanding a return on a timetable. No quarterly targets that have to be fed. No investors waiting for the sale that would make their maths work. Take those away and a great deal of short-termism simply has no source — there is no recurring pressure to bend the product toward this period's number, because there is no number that has to grow this period or else.

What is left is a plainer arrangement: a small team, its own products, and the freedom to build them at the pace the work actually needs. That freedom is not a luxury or a mood — it is structural, and it is the reason the patience in everything else we do is possible. A company can only afford to be unhurried about the durable things if nothing is forcing it to be hurried about the numbers.

Patience as the default, not the virtue

Once the pressure is gone, patience stops being a discipline you have to summon and becomes the obvious way to work. We can decide the hard-to-reverse things slowly, because nothing is demanding we decide them fast. We can keep a product running for the people who rely on it instead of sunsetting it for a strategy, because there is no strategy pulling the other way. We can refuse to sell user data, because there is no quarter whose gap that sale was needed to close.

This is the business half of the long view — the other half of building durable software. The code has to be made to last, and we have written about what that asks of the code. But the code will only be allowed to last if the company around it is shaped to let it. Playing for decades rather than quarters is not a personality trait we are claiming. It is a structure we chose, so that patience would be the default and not a fight we had to win again every ninety days.

Questions

People also ask

    Why does a company's structure affect whether its software lasts?

    Because a business under quarterly pressure will eventually bend its product toward this period's numbers, whatever its engineers intend. With no board, no quarterly targets and no pressure to pivot, there is no recurring force pulling the software away from the long term — so patience becomes the default.