New Motor, Old Belts
The overhead projector had a fan that rattled, and it threw her handwriting three feet high onto the wall. Mine never looked like that. I copied the diagram down anyway: two axes, and between them two lines crossing, a red one falling and a blue one climbing.
Early nineties, A-level Economics at Paston in North Norfolk — the same school, if you go back far enough, as Nelson and Stephen Fry, which at sixteen felt like something you were supposed to be proud of and then forget. The memory is hazy in every respect but one. She put a finger on the supply line, slid the acetate to the right, and the crossing point dropped.
If it gets cheaper to make, more of it gets made and the price comes down. That, she said, is the easy part. The interesting question is not how much. It is what else changes.
I found myself drawing her diagram again last week. Software has become much cheaper to build, and I wanted the graph before I wanted an opinion. Price falls, quantity rises, and that is all the first movement is allowed to say. How far quantity travels has a name of its own — elasticity, which is really a measure of how much people rearrange their lives around a new price. They rearrange far more in the long run than the short, because rearranging takes time. Today's behaviour is a poor guide to eventual behaviour, which is inconvenient if you happen to live in today.
Suppose a hundred organisations buy a piece of software at a hundred pounds. Ten thousand pounds of spend. The price falls to ten. If three hundred buy it, the market has shrunk. If a thousand buy it, nothing has changed except who holds the money. If five thousand buy it, the market is five times what it was, and most of the new buyers are organisations for whom the thing was never worth a hundred pounds and is worth ten. Cheaper software and a smaller software economy are different propositions, and the graph cannot tell you which one you are standing in.
The last time a new kind of power got cheap, the question took forty years to answer. The answer was not a cheaper mill. It was a different mill.
Four hundred lamps
On the fourth of September 1882, Thomas Edison's Pearl Street Station opened in lower Manhattan with about four hundred lamps burning for eighty-two customers. Nearly two decades later the breakthrough was still a curiosity. In 1899 electric lighting reached three per cent of American homes, and electric motors supplied less than five per cent of the mechanical drive in factories. The world had a new kind of power and still looked like the old world.
Walk onto a mill floor in those years and you would have seen why. Force was a single thing, made in one place and delivered everywhere else. A steam engine or a water wheel turned a long iron spine along the ceiling, and leather belts dropped from it to every machine in the building, so that everything in the room answered to the shaft: the machines stood where the shaft required rather than where the work wanted them, the floors were braced to carry spinning iron overhead, the air held oil and noise and the standing risk that a belt would throw and take a hand with it, and when the engine stopped, the whole floor stopped with it.
When electricity arrived, the obvious move was the cheap one. Take out the steam engine. Bolt a large electric motor to the same shaft. Keep the belts.
The factory was electrified. It was not yet an electric factory.
The other move took longer, because it asked something of the building. Instead of one motor turning every belt, each machine got a motor of its own — as if every bench had been given a socket and the ceiling could finally go back to being a ceiling. Once the iron spine came down, the room could be arranged around the work. Lighter construction, with nothing heavy left to brace. Machines that moved when the work moved. A broken tool that no longer stopped the floor. Skylights where the transmission had been. The engineers called it unit drive, a dull name for something that is only interesting once you have watched a room change shape.
By 1929 electricity supplied seventy-eight per cent of manufacturing drive. Manufacturing labour productivity, which had grown at about one and a half per cent a year from 1899 to 1914, grew at over five per cent a year through the 1920s. That is the harvest. It arrived late, and it arrived as a change of shape rather than a cheaper version of the old shape.
The roof had to leak
Why forty years? Not ignorance. Everybody had heard of the motor.
In 1990 an economic historian at Stanford called Paul David published six pages that answered the question, and he was not really writing about mills. He was writing about computers. Three years earlier, reviewing a book about American manufacturing for the New York Times, Robert Solow had written the sentence that hung over the whole decade: "You can see the computer age everywhere but in the productivity statistics." Firms were buying machines by the warehouse and the numbers would not move. David's reply was that this had happened before, and that the reason was accounting rather than stupidity.
Replacing a still-serviceable plant built around the old regime did not pay. The mill had to wear out first. A roof leaks. A belt cracks. A shaft throws a pulley. The owner of a mill that still ran had no occasion to rebuild it and no reason to look for one. Time took the buildings away, and the belts came down with them.
The mills, in other words, were lucky. Decay is a forcing function that arrives free, on a schedule nobody has to approve, and it hands you the question that is otherwise almost impossible to ask inside a working business: given that we are rebuilding anyway, why is the work laid out like this? Call that a depreciation event.
A building rusts. Software does not.
David saw this and said it in the language of information rather than of code. A firm's information structures — the data it collects, and the way it distributes and processes that data — are, he wrote, "direct counterparts of the physical layouts and materials flow patterns of production." They are the ceiling. But unlike buildings and machines they "do not automatically undergo significant physical depreciation." They may become obsolete. They may be scrapped. But "one cannot depend on the mere passage of time to create occasions to radically redesign" them.
So the mill is not a metaphor you can spend and walk away from. The project queue, the ten-year application, the review board built for a world in which software was expensive: those are line shafts. A line shaft, in the sense worth keeping, is any structure designed around a scarce resource that outlives the scarcity. They persist because nothing in them rots. There is no leaking roof to force the question.
Cheap software might supply the missing occasion. When replacement costs less than leaving the current thing in place, rebuilding becomes the rational move, and every rebuild is a chance to ask why the work is still arranged around the belts.
The factories had no choice. We do — and history's first move, handed cheaper power, is not to take the shafts down. It is to bolt a new motor onto them.
The wrong kind of rust
An engineer will object here, and the objection is a good one. Software does decay. Runtimes reach end of life, libraries stop getting patches, a TLS version is withdrawn, a cloud provider gives you eighteen months on the instance type you are standing on, and every week the security feed produces something that has to be looked at. All of it arrives from outside, on a calendar nobody in the firm controls, and much of it carries a deadline — the one thing that reliably moves attention.
Look at what it forces, though. The professional answer to an end-of-life notice is to change as little as possible: port the code, pin the versions, get the tests green, touch no behaviour. Migrations are graded on the smallness of their diff. The answer to a vulnerability is smaller still — bump the dependency, apply the mitigation, close the ticket. The deadline arrives, the work is done properly, and the structure it was done to is the structure that existed the week before. The roof that fell in took the layout with it. A runtime upgrade takes the runtime.
Patching is stranger still, because it never stops. A roof fails once and you rebuild; a system is patched forever, in small increments, and a small continuous cost is precisely the thing that keeps beating a large immediate one. Every patch is a payment towards keeping the old thing alive, and it buys something else besides. A legacy system that is diligently patched does not look like a legacy system. It looks looked-after.
Both kinds of decay can be bought off, too. Extended support exists because somebody will pay to postpone them, an arrangement no mill owner was ever offered. And both spare the oldest things first: a system whose dependencies stopped moving years ago has nothing left upstream to deprecate it. The pressure to change falls as the thing ages, which is the exact reverse of a building.
There is one true forcing function in here, and it shows the shape of the rule. Occasionally something becomes genuinely unpatchable: an exploit in the open with no fix coming, a compliance regime that will not certify it, a security questionnaire it can no longer pass. Then it has to go, and it does go. But look at the conditions. It is an emergency, the date belongs to somebody else, and the only defensible move is to get the dependants across as fast as possible, changing nothing about the way they work. The one force that reliably kills software is also the one that guarantees nobody redesigns anything while it is happening.
So software rusts. The rust is in the wrong place. It eats the substrate and leaves the structure standing, which is how the belts stay up while everything underneath them is replaced.
The cost nobody measures
The opportunity gets deferred because throwing the old thing away is not free.
Economics carries a quiet assumption called free disposal: unwanted things can be discarded at no cost, which is why more is never modelled as worse than less. In the closing paragraphs of the same paper, David argued that the assumption fails for information. Distribution is nearly free, so producers broadcast indiscriminately. Habits formed when information was "previously scarce" predispose us "to try screening whatever becomes available." Screening is work. Across a firm, people end up duplicating one another's effort simply coping, and the coping displaces the work that anyone would think to measure.
That coping is not too many buttons on a screen. It is the evaluation, the security questionnaire, the review meeting, the integration that cannot be unwound, the data sitting inside the tool you would like to turn off. We built that apparatus because a new system used to be a ten-year commitment and deserved a ten-year decision. Apply it unchanged to a world where software can be stood up for a team, or a person, or a single task, and the screening cost climbs with the number of tools. The immune system we built for scarcity treats abundance as an infection. The screening instinct is itself a line shaft.
Decommissioning is the practical cousin and it is expensive in a more familiar way. Software inside a firm is rarely free to discard: it holds data, it has users, permissions and integrations, and somebody's job is shaped around it. Switching a system off can cost more than building its replacement, which is precisely the point at which the replacement gets built and the old system stays on.
Only one of those two costs ever appears in a plan. Building has estimates, budgets, roadmaps and a date, and a firm can usually tell you what a new system will cost to the nearest ten thousand pounds. Retiring one has no such apparatus: no line in the budget called removal, no estimate, nobody whose year is judged by how much of the estate they took away. The cost is real and unpriced, which is a dependable way of making sure it is never paid.
The belt I have not taken down
We run two versions of our API. The second is the shape we would choose if we were starting today, and building it was the easy part. The first one is still running. Our own documentation has described it as scheduled for deprecation for some time now.
It is still running because I cannot see what it holds up. Third parties built on it over the years — integrations, imports, a membership portal, a script somebody's colleague wrote and left behind — and none of that reports home. The logs tell me which endpoints are called and how often. They do not tell me whose Monday breaks if the calls stop being answered. Somewhere in that traffic is a use case nobody here has heard described, doing something load-bearing for an organisation that has no idea it is the only one doing it.
I could find out. The work is not mysterious: log every call at the edge, watch for a quarter, match the callers back to accounts, then ring the organisations the traffic points at and ask them what they are doing. I have started versions of that more than once.
None of them finished, and not because the work is hard. Running v1 costs almost nothing — some compute, an occasional patch, a line in a diagram. Retiring it costs attention, which is the one budget with nothing spare in it. A cost that is tiny and continuous beats a cost that is large and immediate every time you set them side by side, and you set them side by side every quarter, and the answer never changes: something more urgent has arrived, or something more interesting, and both win easily. Both should. That is what a local minimum feels like from the inside — not inertia, but a run of individually correct decisions that never add up to the thing you said you would do.
It has been carried across a runtime it was not written for, which is its own small proof of the point. The deadline came from outside, somebody did the work properly, and nobody used the occasion to ask what v1 was for.
The mill owner had a leaking roof to settle the argument for him. I have a system that works. A new motor, and the old belts still turning, in the same building, indefinitely.
Everyone is watching the cost of building fall. The cost of throwing away has not moved at all, and it is now the part that decides the outcome. A folder of applications nobody uses is not evidence that demand expanded. It is evidence that creation got cheap while disposal did not.
The belts everyone has
In 2019 MuleSoft asked six hundred and fifty IT leaders at large companies how the year had gone. Nearly two-thirds said they had not managed to complete all their projects. They had been asked to take on a third more work, and their budgets had grown by less than a tenth. Nobody in that survey treated the queue as the problem. The queue was simply the weather. But a queue is a rationing mechanism for scarce supply, and rationing mechanisms do not dismantle themselves when the scarcity ends. It persists because filling it, prioritising it and reporting on it has become its own justification. The annual software budget is the same structure drawn on a calendar.
The other shaft is the shape of the work. We buy a general-purpose application because a fitted one used to be unaffordable, then standardise the work around whatever the application can do. We tolerate a manual hand-off because it is too small to justify a project of its own. We expect the result to last a decade, because that is how long it took to pay for. The ten-year application is a line shaft, and the work bent around it is the belt.
Each of these has a version one inside it: something that still works, costs almost nothing to keep, and would cost a quarter of somebody's attention to remove. That is the arithmetic that keeps them all turning.
If disposal were cheap the estate would change shape: far more software, most of it serving smaller audiences, some of it short-lived, arranged around the work rather than around the applications, with shared identity and shared data underneath many small tools. A motor on each machine. That trades one concentration for another — whoever controls the shared layer controls the floor — so unit drive for software is a new geometry for line shafts rather than the end of them. And none of it counts while the old applications are still running, still being screened, still being integrated, still being supported. Unit drive with the shafts left up is just more motors.
The second shift
David ended his own analogy with a warning. "Computers are not dynamos." A payroll system and an image editor are not interchangeable units. Copying software does not consume it. The network already exists, so the technical half can be fast while the firm stays slow.
One break cuts the other way. The dynamo could not design the electric factory: the complementary ideas had to be worked out one plant at a time, by what David called a cadre of factory architects and electrical engineers, learning that was slow because demand for new factories was slow. The tools that make software cheap can help design the rooms it needs. That may shorten the learning. It does not shorten the redesign, and it does not make the old belts cheaper to take down.
I have no tidy date by which the belts come down. David thought economic history should help us avoid "both the pitfall of undue sanguinity and the pitfall of unrealistic impatience", which still seems the right posture. The geometry of a firm does not move until two things are true at once: rebuilding is cheaper than leaving the belts up, and taking the belts down is actually allowed.
On the acetate, that is a second shift. At first only supply moved. Price fell, quantity rose, and the room still looked like the old room. Eventually demand moves too — people find uses that were uneconomic before, and rearrange the furniture around them. That is when the larger change starts, and it is the part of the diagram she never drew, because you cannot draw a curve that only moves once the building has been allowed to fall down.
The interesting question was never how much. It was what else changes, and whether we will let it.
Postscript, and an entirely sincere one. If you build against the sheepCRM v1 API, I would like to hear from you: what you call, and what it does at your end. Every use case somebody describes to me is one more belt I can actually see.