Cheaper software means more software

The pattern is old enough to have a name

In 1865 William Stanley Jevons noticed that improvements to the steam engine, which used less coal per unit of work, were followed by Britain burning far more coal, not less. Efficiency lowered the price of using coal, lower prices raised demand, and demand outran the saving. The effect carries his name.

Software has run this pattern repeatedly, and it is the single most useful frame for thinking about what happens next to the amount of work available.

Two worked cases

Bank tellers and cash machines. The economist James Bessen’s well-known telling: ATMs spread through American banking from the 1970s, and each branch needed fewer tellers. Cheaper branches meant banks opened more branches, and total teller employment in the United States rose for roughly three decades after the machine that was supposed to replace them. The job changed (less cash counting, more selling and customer handling) before eventually declining for other reasons, mostly online banking. Both halves are true and people quote only the half that suits them.

Spreadsheets and accounting. VisiCalc, Lotus 1-2-3 and Excel automated the thing that had defined the clerical layer of finance: recalculating a grid of numbers by hand. The commonly cited pattern in US labour statistics is that bookkeeping and accounting clerk roles declined over the following decades while accountants and auditors grew. The automation did not delete the field; it deleted a rung and expanded the layer above it, because analysis that had been too expensive to perform became routine.

Both are cases of the same mechanism: making a task cheap moves work that was previously not worth doing across the line into being worth doing.

Every organisation has a backlog it cannot afford

This is the concrete version for software, and it is easy to verify in your own workplace.

A thirty-person warehouse runs on a spreadsheet, three WhatsApp groups and a whiteboard. Somebody has wanted a small tool for six years that would take a picked order, print a label and update stock. At three weeks of an engineer’s time it was never worth it. At two afternoons it is obviously worth it.

Multiply that by every department in every organisation. The queue of software that is wanted and unaffordable is not slightly longer than the queue of software that gets built. It is enormous. Internal tools, one-off migrations, small integrations between two systems that do not talk, reports somebody currently assembles by hand every Friday.

That backlog is the reason the naive substitution argument (the same work, done by fewer people) has been wrong every time. The work is not fixed.

Where the argument stops working, and it does stop

Induced demand is not a law of nature, and treating it as reassurance is a mistake. It requires two conditions: unmet demand must exist, and somebody must be able to pay for it. Where either fails, the cost reduction shows up as fewer jobs and lower prices instead of more output.

The segments most exposed are the ones where the demand was largely met and the product was mostly the labour: simple marketing sites, basic content-management builds, straightforward CRUD applications sold as bespoke work, template-level app development. If your service was I will type the thing you could describe, the price of that service is falling, and the market may not expand to compensate because there was not a hidden queue of people wanting a fifth brochure site.

The segments least exposed are those where the constraint was never the typing: regulated systems, anything needing domain judgement, anything where being wrong is expensive, and anything requiring integration into a mess that nobody has documented.

The maintenance bill nobody prices

Here is the part that is missing from most versions of this argument.

Software is not a purchase, it is a subscription to a liability. Every system that exists must be patched, upgraded when its dependencies move, migrated when its database version reaches end of life, secured, monitored, and understood by somebody when it fails at 3am. That cost is roughly proportional to how much software exists, and it is almost entirely composed of the activities that did not get cheaper.

So the induced demand argument has a sting in its tail. If cheap generation triples the amount of software in the world over a decade, it triples the maintenance surface, and maintenance is dominated by understanding and verifying rather than writing. That produces more work, not less, but of a specific kind, and not necessarily distributed to the same people.

What to do with this

Two practical conclusions.

If you are deciding what to learn, weight towards the parts of the job that the backlog will demand more of: understanding an unfamiliar system, deciding what should be built, and confirming it works. Weight away from being the fastest producer of code whose specification somebody else wrote.

If you are running a team, notice that your backlog just became affordable, and that this is a trap as well as an opportunity. Building everything you can now afford to build is how you acquire a maintenance bill you cannot pay in three years. The discipline of saying no to software got more valuable at exactly the moment it got harder to justify.