The Cost and Lifecycle of Software
The 80/20 Rule of Lifecycle Cost
One of the most important economic realities in software engineering is this: only about 20% of a software system’s total lifetime cost is spent on initial development; roughly 80% is spent on maintenance and evolution.
This has a profound implication: code must be written for the engineer who reads it five or ten years from now, not optimised purely for the speed of initial writing. A clever one-liner that saves 10 minutes today but takes a future maintainer 3 hours to decipher is a net loss. Readability, clear structure, and explicit intent are economic virtues, not aesthetic preferences.
The Four Types of Maintenance
Software maintenance is not a monolithic activity. It falls into four categories, each with different triggers and cost profiles:
| Type | Description | Typical effort share |
|---|---|---|
| Corrective | Fixing bugs discovered by users after deployment | ~20% |
| Adaptive | Making the system work in a changed environment (new OS, new hardware, cloud migration, new tax regulations) | ~25% |
| Perfective | Adding new features or improving performance demanded by users; improving maintainability or readability without changing behaviour | ~50% |
| Preventive | Refactoring code to prevent future decay; finding and fixing latent problems before they become actual bugs | ~5% |
The striking observation is that most maintenance effort (~50%) is perfective — keeping the system relevant and competitive by adding features and improving performance. Only ~20% is about fixing bugs. Software is maintained not because it is broken, but because the world around it changes and user expectations rise.
Bit Rot (Software Entropy)
Software does not physically wear out in the sense that metal fatigues or concrete crumbles. A .c file from 1995, stored on a disk, will contain exactly the same bytes in 2025.
Yet software that is never touched will eventually stop working. The surrounding environment changes around it:
- Libraries are updated or deprecated; newer versions break old APIs.
- Security protocols are deprecated (TLS 1.0, SSLv3); servers stop accepting old connections.
- Operating system APIs change; the old syscall is removed.
- Hardware interfaces evolve; the driver model from 2005 no longer compiles.
The software’s own source code never changed — but the world it was written for no longer exists. This phenomenon is called bit rot or software entropy. It means that even a “finished” system requires ongoing adaptive maintenance simply to continue functioning, which reinforces the economics of the 80/20 rule.
The Four Dimensions of Lifespan Cost
Beyond the initial-development vs maintenance split, there are several reasons maintenance dominates:
-
The reading-to-writing ratio. Engineers spend far more time reading code than writing it — estimates range from 10:1 to 20:1. Every minute spent making code clear saves many minutes of future reading.
-
Accumulating technical debt. Quick fixes and shortcuts compound. A small corner cut in version 1.0 becomes a tangled mess by version 5.0, requiring exponentially more effort to change.
-
Dependency churn. Modern software depends on hundreds of third-party libraries (npm, PyPI, Maven). Each must be updated periodically for security patches and compatibility, even if your own code hasn’t changed.
-
Regulatory and compliance drift. Tax laws change, data-protection regulations (GDPR, CCPA) evolve, accessibility standards rise — all of which may require modifications to existing, working software.
Code as a Liability
A counterintuitive insight from lifecycle economics: lines of code are a liability, not an asset. Managers often view code quantity as a measure of progress, but every line written must be:
- Tested
- Maintained
- Secured
- Understood by future engineers
- Kept compatible with evolving dependencies
The best code is the code you did not have to write. Simpler solutions that achieve the same outcome with fewer lines, fewer dependencies, and fewer moving parts produce less maintenance burden over the decades of the system’s life.
Expected Learning
- State the 80/20 rule and explain its implications for how code should be written.
- Name and distinguish the four types of maintenance with their typical effort shares.
- Explain what bit rot is, why it occurs, and what kind of maintenance addresses it.
- Justify why lines of code should be viewed as a liability rather than an asset.
Past Paper Questions
In scenario-based questions, you may be asked to argue why investing in test suites, documentation, or clean architecture is economically rational. The 80/20 rule and the four maintenance types give you the quantitative framing to do so: a decision that seems expensive at development time is often cheap compared to the decades of maintenance work it enables or hinders.