{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"induced-demand-for-software","title":"Cheaper software means more software","url":"https://addaly.com/learn/how-software-changed/induced-demand-for-software","position":3,"of":87,"minutes":9,"answer":"Making software cheap to produce expands what gets built rather than shrinking the work, but it expands the maintenance surface at the same rate.","keyIdea":"Making software cheap to produce expands what gets built rather than shrinking the work, but it expands the maintenance surface at the same rate, and maintenance is made of the activities that did not get cheaper."},"body":{"format":"markdown","text":"## The pattern is old enough to have a name\n\nIn 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.\n\nSoftware 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.\n\n## Two worked cases\n\n**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.\n\n**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.\n\nBoth 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.\n\n## Every organisation has a backlog it cannot afford\n\nThis is the concrete version for software, and it is easy to verify in your own workplace.\n\nA 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.\n\nMultiply 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.\n\nThat 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.\n\n## Where the argument stops working, and it does stop\n\nInduced 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.\n\nThe 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.\n\nThe 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.\n\n## The maintenance bill nobody prices\n\nHere is the part that is missing from most versions of this argument.\n\nSoftware 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.\n\nSo 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.\n\n## What to do with this\n\nTwo practical conclusions.\n\nIf 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.\n\nIf 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."},"check":{"question":"A consultancy that builds bespoke CRUD applications for small firms sees its build time drop by two thirds. Its owner assumes revenue will hold because the backlog of unbuilt software is enormous. What is the flaw in that reasoning?","options":[{"text":"Induced demand only applies to physical goods like coal and cash machines, not to services, where price and demand are unrelated.","correct":false,"tempting":"Invents a boundary that does not exist; the mechanism is about price and demand, and applies to any good whose cost falls."},{"text":"Backlogs are usually imaginary, because firms that say they want software rarely commission it even when the price falls.","correct":false,"tempting":"Denies the unmet demand outright, when the observable pattern in most organisations is a real and long list of wanted, unaffordable tools."},{"text":"The backlog will absorb the capacity, but only after a lag of several years, so the firm needs cash reserves rather than a change of strategy.","correct":false,"tempting":"Treats a structural exposure as a timing problem, which leads to waiting out a decline that will not reverse."},{"text":"Its clients can now build the simple application themselves, so its price falls without its volume rising.","correct":true}]},"prev":{"slug":"the-fifth-time-code-got-cheap","title":"The fifth time code got cheap","url":"https://addaly.com/learn/how-software-changed/the-fifth-time-code-got-cheap"},"next":{"slug":"reading-a-productivity-study","title":"How to read a claim about developer productivity","url":"https://addaly.com/learn/how-software-changed/reading-a-productivity-study"},"authorship":"Founder and series editor: Dr Mustafa Mun. Written by AI models to a written standard. Exam keys checked blind by a second model: 3,665 of 3,666 agreed. Academic review invited.","review":{"status":"Draft, open for academic review"},"cite":"Addaly (2026) 'Cheaper software means more software', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/induced-demand-for-software (Accessed: 13 October 2026).","licence":{"name":"CC BY-NC-SA 4.0","url":"https://creativecommons.org/licenses/by-nc-sa/4.0/"},"reader":{"schema":1,"title":"Cheaper software means more software","courseTitle":"How Software Development Changed","module":{"index":1,"slug":"where-the-cost-went","title":"Where the cost actually went"},"answer":null,"keyIdea":"Making software cheap to produce expands what gets built rather than shrinking the work, but it expands the maintenance surface at the same rate, and maintenance is made of the activities that did not get cheaper.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-pattern-is-old-enough-to-have-a-name","runs":[{"text":"The pattern is old enough to have a name"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"two-worked-cases","runs":[{"text":"Two worked cases"}]},{"t":"p","runs":[{"text":"Bank tellers and cash machines.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"Spreadsheets and accounting.","b":true},{"text":" 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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"every-organisation-has-a-backlog-it-cannot-afford","runs":[{"text":"Every organisation has a backlog it cannot afford"}]},{"t":"p","runs":[{"text":"This is the concrete version for software, and it is easy to verify in your own workplace."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"where-the-argument-stops-working-and-it-does-stop","runs":[{"text":"Where the argument stops working, and it does stop"}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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 "},{"text":"I will type the thing you could describe","i":true},{"text":", 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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"the-maintenance-bill-nobody-prices","runs":[{"text":"The maintenance bill nobody prices"}]},{"t":"p","runs":[{"text":"Here is the part that is missing from most versions of this argument."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"h2","id":"what-to-do-with-this","runs":[{"text":"What to do with this"}]},{"t":"p","runs":[{"text":"Two practical conclusions."}]},{"t":"p","runs":[{"text":"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."}]},{"t":"p","runs":[{"text":"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."}]}],"check":{"question":[{"text":"A consultancy that builds bespoke CRUD applications for small firms sees its build time drop by two thirds. Its owner assumes revenue will hold because the backlog of unbuilt software is enormous. What is the flaw in that reasoning?"}],"options":[{"text":[{"text":"Induced demand only applies to physical goods like coal and cash machines, not to services, where price and demand are unrelated."}],"correct":false,"tempting":[{"text":"Invents a boundary that does not exist; the mechanism is about price and demand, and applies to any good whose cost falls."}]},{"text":[{"text":"Backlogs are usually imaginary, because firms that say they want software rarely commission it even when the price falls."}],"correct":false,"tempting":[{"text":"Denies the unmet demand outright, when the observable pattern in most organisations is a real and long list of wanted, unaffordable tools."}]},{"text":[{"text":"The backlog will absorb the capacity, but only after a lag of several years, so the firm needs cash reserves rather than a change of strategy."}],"correct":false,"tempting":[{"text":"Treats a structural exposure as a timing problem, which leads to waiting out a decline that will not reverse."}]},{"text":[{"text":"Its clients can now build the simple application themselves, so its price falls without its volume rising."}],"correct":true,"tempting":null}],"order":[1,0,3,2],"why":null},"prev":{"slug":"the-fifth-time-code-got-cheap","title":"The fifth time code got cheap","minutes":9},"next":{"slug":"reading-a-productivity-study","title":"How to read a claim about developer productivity","minutes":10}}}