{"course":{"slug":"how-software-changed","title":"How Software Development Changed","url":"https://addaly.com/learn/how-software-changed","level":"intermediate","track":"work"},"lesson":{"slug":"the-ten-year-cost","title":"Writing cost, and the cost that follows it","url":"https://addaly.com/learn/how-software-changed/the-ten-year-cost","position":82,"of":87,"minutes":9,"answer":"Generation cut the cost of writing code and not the cost of keeping it, while plausibly raising the second through volume, duplicated concepts and absent reasoning.","keyIdea":"Generation cut the cost of writing code and not the cost of keeping it, while plausibly raising the second through volume, duplicated concepts and absent reasoning, so review and design should optimise for how few distinct concepts a system contains rather than for how fast each part arrived."},"body":{"format":"markdown","text":"## The part of the bill nobody sees at the start\n\nA line of code is paid for twice: once when written, and continuously thereafter by everyone who has to read it, change it, patch it and reason around it.\n\nThe old surveys put the second half at somewhere between half and four-fifths of total lifecycle cost. Lientz and Swanson surveyed several hundred organisations in 1980 and found roughly half of effort going to maintenance; later estimates ran higher. Treat those numbers with suspicion: they are old, self-reported, and everyone defined \"maintenance\" differently. The direction is robust even where the fraction is not: the majority of what software costs happens after it first works.\n\nGeneration cut the first payment substantially. It cut the second payment by nothing at all, and there is an argument, unproven, that it raised it.\n\n## Why the second payment might have gone up\n\nThree mechanisms, each plausible and none measured.\n\n**Volume.** More code exists per unit of delivered function, because generating an abstraction that removes duplication is more work than generating the duplication. Every line carries maintenance cost.\n\n**Fewer shared concepts.** A person building a system converges: they invent a helper, then reuse it. A generator invoked separately on similar problems produces four similar-but-different solutions, because it does not remember the other three. The codebase ends up with four date parsers.\n\n**Nobody holds the model.** The most expensive property of a legacy system is not that the code is bad; it is that the reasoning is gone. Code accepted rather than authored starts in that state on day one. Module six covered onboarding without an author; this is the same problem measured over years instead of weeks.\n\nI want to be exact about the epistemic status: this is a mechanism argument. The oldest substantially generated codebases are about three years old, and maintenance costs become visible at five to ten. Nobody has the data yet, and anyone claiming to is extrapolating.\n\n## What makes code cheap to keep\n\nNotably, not the same things that make it fast to write.\n\n**Fewer distinct concepts.** Ten modules using one date library and one error convention is cheaper than ten modules each locally optimal. Consistency beats local quality for maintenance, which is a counterintuitive claim and the reason style guides exist.\n\n**Deletability.** Can this be removed without archaeology? Clear boundaries and few reverse dependencies are what let a system shrink, and a system that can never shrink only grows.\n\n**Boring choices.** The widely used library with five years of history costs less over a decade than the elegant one with a single maintainer, whatever the comparison looks like today.\n\n**Fewer dependencies.** Each is a permanent obligation to track advisories, absorb breaking changes and eventually migrate. Dependency count is debt that accrues interest whether or not you touch the code.\n\n## Two measurements you can take this week\n\n**Count the ways.** Pick something your codebase does repeatedly: parse a date, retry a call, format money, check a permission. Count the distinct implementations. Most teams find three to six where they expected one, and the number is a direct proxy for what a change will cost. Track it quarterly.\n\n**Try to delete something.** Pick a feature you believe is unused. Attempt removal. How long it takes, and how many surprises you hit, is a measurement of coupling that no static metric gives you. If nothing can be removed, the system will only ever get more expensive.\n\n## What follows for practice\n\n**Consolidate on a schedule.** Module six argued this as process; here is the cost argument behind it. The fourth date parser costs nothing to add and something every month forever.\n\n**Review for concept count, not only correctness.** \"This is correct, and it is the third way we do this\" is a legitimate rejection, and it is the review comment most often swallowed because it feels pedantic.\n\n**Justify dependencies against a decade.** Not \"does this work\" but \"am I willing to own the migration when it is abandoned\".\n\n**Write down why, not what.** The reasoning is the expensive artefact, it is the one generation does not produce, and a three-line commit message explaining a rejected alternative may be the highest-value thing you write that day.\n\n> The question that separates cheap systems from expensive ones is not \"how long did this take to build\". It is \"how long does it take a stranger to change it safely\", and that number is set by decisions made when nobody was measuring it."},"check":{"question":"Why does consistency across modules reduce maintenance cost even when each inconsistent module is individually well written?","options":[{"text":"Consistent code compresses better in version control, reducing repository size and clone times.","correct":false,"tempting":"A storage effect with no bearing on the cost of understanding or changing the system."},{"text":"Inconsistent modules are more likely to contain defects, because deviation from convention signals haste.","correct":false,"tempting":"Assumes deviation implies lower quality, which the question explicitly rules out."},{"text":"Static analysis tools require uniform patterns, so inconsistency reduces what automated checks can catch.","correct":false,"tempting":"Tools handle varied patterns; the cost falls on humans reading the system, not on the analysers."},{"text":"A change means learning several conventions instead of one, and that cost recurs per reader.","correct":true}]},"prev":{"slug":"domain-knowledge-as-the-moat","title":"The facts that exist in no corpus","url":"https://addaly.com/learn/how-software-changed/domain-knowledge-as-the-moat"},"next":{"slug":"what-it-costs-to-leave","title":"Ask the exit question before you enter","url":"https://addaly.com/learn/how-software-changed/what-it-costs-to-leave"},"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) 'Writing cost, and the cost that follows it', in How Software Development Changed. Edited by M. Mun. Addaly. Available at: https://addaly.com/learn/how-software-changed/the-ten-year-cost (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":"Writing cost, and the cost that follows it","courseTitle":"How Software Development Changed","module":{"index":9,"slug":"what-did-not-change","title":"What did not change, and what to do now"},"answer":null,"keyIdea":"Generation cut the cost of writing code and not the cost of keeping it, while plausibly raising the second through volume, duplicated concepts and absent reasoning, so review and design should optimise for how few distinct concepts a system contains rather than for how fast each part arrived.","hero":{"kind":"plate","image":null,"alt":null,"caption":null},"blocks":[{"t":"h2","id":"the-part-of-the-bill-nobody-sees-at-the-start","runs":[{"text":"The part of the bill nobody sees at the start"}]},{"t":"p","runs":[{"text":"A line of code is paid for twice: once when written, and continuously thereafter by everyone who has to read it, change it, patch it and reason around it."}]},{"t":"p","runs":[{"text":"The old surveys put the second half at somewhere between half and four-fifths of total lifecycle cost. Lientz and Swanson surveyed several hundred organisations in 1980 and found roughly half of effort going to maintenance; later estimates ran higher. Treat those numbers with suspicion: they are old, self-reported, and everyone defined “maintenance” differently. The direction is robust even where the fraction is not: the majority of what software costs happens after it first works."}]},{"t":"p","runs":[{"text":"Generation cut the first payment substantially. It cut the second payment by nothing at all, and there is an argument, unproven, that it raised it."}]},{"t":"h2","id":"why-the-second-payment-might-have-gone-up","runs":[{"text":"Why the second payment might have gone up"}]},{"t":"p","runs":[{"text":"Three mechanisms, each plausible and none measured."}]},{"t":"p","runs":[{"text":"Volume.","b":true},{"text":" More code exists per unit of delivered function, because generating an abstraction that removes duplication is more work than generating the duplication. Every line carries maintenance cost."}]},{"t":"p","runs":[{"text":"Fewer shared concepts.","b":true},{"text":" A person building a system converges: they invent a helper, then reuse it. A generator invoked separately on similar problems produces four similar-but-different solutions, because it does not remember the other three. The codebase ends up with four date parsers."}]},{"t":"p","runs":[{"text":"Nobody holds the model.","b":true},{"text":" The most expensive property of a legacy system is not that the code is bad; it is that the reasoning is gone. Code accepted rather than authored starts in that state on day one. Module six covered onboarding without an author; this is the same problem measured over years instead of weeks."}]},{"t":"p","runs":[{"text":"I want to be exact about the epistemic status: this is a mechanism argument. The oldest substantially generated codebases are about three years old, and maintenance costs become visible at five to ten. Nobody has the data yet, and anyone claiming to is extrapolating."}]},{"t":"h2","id":"what-makes-code-cheap-to-keep","runs":[{"text":"What makes code cheap to keep"}]},{"t":"p","runs":[{"text":"Notably, not the same things that make it fast to write."}]},{"t":"p","runs":[{"text":"Fewer distinct concepts.","b":true},{"text":" Ten modules using one date library and one error convention is cheaper than ten modules each locally optimal. Consistency beats local quality for maintenance, which is a counterintuitive claim and the reason style guides exist."}]},{"t":"p","runs":[{"text":"Deletability.","b":true},{"text":" Can this be removed without archaeology? Clear boundaries and few reverse dependencies are what let a system shrink, and a system that can never shrink only grows."}]},{"t":"p","runs":[{"text":"Boring choices.","b":true},{"text":" The widely used library with five years of history costs less over a decade than the elegant one with a single maintainer, whatever the comparison looks like today."}]},{"t":"p","runs":[{"text":"Fewer dependencies.","b":true},{"text":" Each is a permanent obligation to track advisories, absorb breaking changes and eventually migrate. Dependency count is debt that accrues interest whether or not you touch the code."}]},{"t":"h2","id":"two-measurements-you-can-take-this-week","runs":[{"text":"Two measurements you can take this week"}]},{"t":"p","runs":[{"text":"Count the ways.","b":true},{"text":" Pick something your codebase does repeatedly: parse a date, retry a call, format money, check a permission. Count the distinct implementations. Most teams find three to six where they expected one, and the number is a direct proxy for what a change will cost. Track it quarterly."}]},{"t":"p","runs":[{"text":"Try to delete something.","b":true},{"text":" Pick a feature you believe is unused. Attempt removal. How long it takes, and how many surprises you hit, is a measurement of coupling that no static metric gives you. If nothing can be removed, the system will only ever get more expensive."}]},{"t":"h2","id":"what-follows-for-practice","runs":[{"text":"What follows for practice"}]},{"t":"p","runs":[{"text":"Consolidate on a schedule.","b":true},{"text":" Module six argued this as process; here is the cost argument behind it. The fourth date parser costs nothing to add and something every month forever."}]},{"t":"p","runs":[{"text":"Review for concept count, not only correctness.","b":true},{"text":" “This is correct, and it is the third way we do this” is a legitimate rejection, and it is the review comment most often swallowed because it feels pedantic."}]},{"t":"p","runs":[{"text":"Justify dependencies against a decade.","b":true},{"text":" Not “does this work” but “am I willing to own the migration when it is abandoned”."}]},{"t":"p","runs":[{"text":"Write down why, not what.","b":true},{"text":" The reasoning is the expensive artefact, it is the one generation does not produce, and a three-line commit message explaining a rejected alternative may be the highest-value thing you write that day."}]},{"t":"quote","runs":[{"text":"The question that separates cheap systems from expensive ones is not “how long did this take to build”. It is “how long does it take a stranger to change it safely”, and that number is set by decisions made when nobody was measuring it."}]}],"check":{"question":[{"text":"Why does consistency across modules reduce maintenance cost even when each inconsistent module is individually well written?"}],"options":[{"text":[{"text":"Consistent code compresses better in version control, reducing repository size and clone times."}],"correct":false,"tempting":[{"text":"A storage effect with no bearing on the cost of understanding or changing the system."}]},{"text":[{"text":"Inconsistent modules are more likely to contain defects, because deviation from convention signals haste."}],"correct":false,"tempting":[{"text":"Assumes deviation implies lower quality, which the question explicitly rules out."}]},{"text":[{"text":"Static analysis tools require uniform patterns, so inconsistency reduces what automated checks can catch."}],"correct":false,"tempting":[{"text":"Tools handle varied patterns; the cost falls on humans reading the system, not on the analysers."}]},{"text":[{"text":"A change means learning several conventions instead of one, and that cost recurs per reader."}],"correct":true,"tempting":null}],"order":[1,2,0,3],"why":null},"prev":{"slug":"domain-knowledge-as-the-moat","title":"The facts that exist in no corpus","minutes":9},"next":{"slug":"what-it-costs-to-leave","title":"Ask the exit question before you enter","minutes":8}}}