The software industry treats software rot as an engineering problem. Code degrades. Dependencies break. Systems slow down. The standard response is technical: refactor the code, update the dependencies, optimize the queries. This paper argues that software rot is not a technical problem. It is a policy failure. Software rots because organizations do not reward maintenance. The engineer who built the system was promoted or left. The team that maintained it was reorganized. The company that owned it was acquired. The code decays not because code inevitably decays but because institutions do not fund, staff, or celebrate the work of keeping old software alive. We trace the lifecycle of abandoned software inside organizations, identify the organizational failures that cause rot, and propose a stewardship model where maintenance is a first class function, not an afterthought.
Why software rots is an organizational failure, not a technical inevitability. The lifecycle of abandoned software. Six principles of software stewardship.
1. Introduction
Software rot is the gradual degradation of a working system over time. It manifests as slower performance, increased failure rates, growing technical debt, and eventual abandonment.
The industry’s explanation for rot is technical. Code ages. Dependencies become outdated. Requirements change. The original developers leave. Entropy wins.
This explanation is convenient because it absolves the organization. If rot is a natural property of software, like rust on metal, then no one is responsible. It just happens.
This paper rejects that explanation. Software does not rot like metal rusts. Software rots like a building crumbles when no one maintains it. The rot is not in the materials. It is in the absence of care.
And the absence of care is an organizational choice.
flowchart LR
A["Industry narrative: rot is inevitable"] --> B["Natural property of code"]
A --> C["Like rust on metal"]
A --> D["No one is responsible"]
E["Actual cause: absence of care"] --> F["Organizational choice"]
E --> G["Funding not allocated"]
E --> H["Maintenance not rewarded"]2. The Lifecycle of Abandoned Software
Every piece of abandoned software follows a predictable trajectory.
timeline
title Lifecycle of Abandoned Software
Phase 1 - Creation : Team builds something : It works : Engineers are engaged
Phase 2 - Success : System is used : New features added : Original team moves on
Phase 3 - Handover : New team inherits : Measured on features : Not system health
Phase 4 - Decay : Shortcuts taken : Dependencies not upgraded : Knowledge fades
Phase 5 - Crisis : Critical failure : Cannot upgrade : Production outage
Phase 6 - Abandonment : Rewrite chosen : Cycle begins againPhase 1: Creation
A team builds something. It works. It solves a problem. The engineers are engaged. The code is clean. Tests exist. Documentation is written. The system is deployed.
Phase 2: Success
The system is used. It becomes important. More features are added. More users depend on it. The team that built it is celebrated. The engineers who built it are promoted or reassigned to the next important project.
Phase 3: Handover
The original team moves on. A new team inherits the system. The new team did not design it. They do not fully understand it. They are responsible for maintaining it while also building new features. They are measured on feature delivery, not system health.
Phase 4: Decay
Under pressure to deliver features, the new team takes shortcuts. Tests are skipped. Documentation is not updated. Dependencies are not upgraded. The codebase accumulates patches on patches. Institutional knowledge fades. The people who understood why certain decisions were made are gone.
Phase 5: Crisis
The system fails. A dependency has a critical vulnerability but upgrading it breaks the application. A database query that worked for years suddenly times out under increased load. A bug that no one understands causes a production outage. The organization scrambles.
Phase 6: Abandonment or Rewrite
The organization faces a choice: invest heavily in rescuing the system or rewrite it from scratch. The rewrite is chosen because building new things is more rewarding than fixing old things. The cycle begins again.
3. The Organizational Failures That Cause Rot
Failure 1: Maintenance Is Not Funded
Budgets are allocated to new projects. New features. New products. Maintenance is expected to happen in the margins, during “slack time” that does not exist. When a team is asked to deliver features and maintain systems, features win. Features are visible. Maintenance is invisible.
Failure 2: Maintenance Is Not Measured
Organizations measure what they value. Feature velocity. Revenue growth. User acquisition. System health is rarely measured with the same rigor. Uptime is tracked. But code quality, test coverage, dependency freshness, and documentation accuracy are not executive level metrics. What is not measured is not managed. What is not managed decays.
Failure 3: Maintenance Is Not Rewarded
Engineers who build new systems are promoted. Engineers who maintain old systems are overlooked. The career incentive is clear: build, do not maintain. The result is that the most experienced engineers, the ones who best understand the systems, are the first to leave maintenance roles. The systems are left to junior engineers who lack the context to maintain them properly.
Failure 4: Institutional Memory Is Not Preserved
When an engineer leaves, their knowledge leaves with them. Code comments capture what the code does. They rarely capture why it does it that way, what alternatives were considered, or what constraints shaped the design. Architecture decision records exist in some organizations but are not standard practice. The result is that future maintainers must reverse engineer intent from implementation. They make changes that violate original assumptions because they do not know those assumptions existed.
Failure 5: Dependencies Are Not Managed
Modern software depends on hundreds of third party libraries. Each dependency is a maintenance obligation. It will release updates. It will have vulnerabilities. It will eventually be deprecated. Organizations that do not budget time for dependency management accumulate a growing backlog of outdated dependencies. Eventually, a critical update becomes impossible because the system is too far behind. The software is trapped in the past.
block-beta
columns 2
block:F1["Maintenance Not Funded"]
columns 1
F1a["Budget goes to new features"]
F1b["No slack time exists"]
end
block:F2["Maintenance Not Measured"]
columns 1
F2a["Feature velocity tracked"]
F2b["System health ignored"]
end
block:F3["Maintenance Not Rewarded"]
columns 1
F3a["Builders are promoted"]
F3b["Maintainers are overlooked"]
end
block:F4["Memory Not Preserved"]
columns 1
F4a["Knowledge leaves with people"]
F4b["Intent is lost"]
end
block:F5["Dependencies Not Managed"]
columns 1
F5a["Outdated libraries accumulate"]
F5b["Critical upgrades become impossible"]
end
F1 --> ROT["SOFTWARE ROT"]
F2 --> ROT
F3 --> ROT
F4 --> ROT
F5 --> ROT4. The Stewardship Model
The alternative to abandonment is stewardship. Stewardship is the practice of maintaining software as a first class function, with dedicated resources, clear metrics, and institutional recognition.
block-beta
columns 2
block:P1["Funded Maintenance"]
columns 1
P1a["20-30% of engineering time"]
P1b["Protected from feature pressure"]
end
block:P2["System Health Measurement"]
columns 1
P2a["Health score per system"]
P2b["Reported at executive level"]
end
block:P3["Career-Advancing Maintenance"]
columns 1
P3a["Evaluated on system health"]
P3b["Stewardship equals creation"]
end
block:P4["Architecture Decision Records"]
columns 1
P4a["Captures why, not just what"]
P4b["Stored with the code"]
end
block:P5["Active Dependency Management"]
columns 1
P5a["Continuous minor updates"]
P5b["Flagged for replacement"]
end
block:P6["Planned Sunsetting"]
columns 1
P6a["90 day minimum notice"]
P6b["Data export tooling"]
endPrinciple 1: Maintenance Is a Funded Activity
A percentage of engineering capacity is allocated to maintenance. Not 5 percent left over after features. Not “when we have time.” A dedicated allocation. Twenty to thirty percent of engineering time is budgeted for system health: dependency updates, test improvements, documentation updates, performance optimization, and code cleanup. This allocation is protected from feature pressure.
Principle 2: System Health Is Measured and Reported
Every system has a health score. The score includes: test coverage, dependency freshness, documentation completeness, known bug count, mean time to recovery, and deployment frequency. The score is reported at the same level as feature velocity and revenue metrics. A declining health score triggers a response, just as a declining revenue metric would.
Principle 3: Maintenance Is Career Advancing
Engineers are evaluated on system health, not just feature delivery. Maintaining a system for three years, improving its reliability, reducing its technical debt, and documenting its architecture is valued equally with building a new system. Senior engineers are expected to demonstrate stewardship, not just creation.
Principle 4: Architecture Decisions Are Recorded
Every significant architectural decision is documented in an Architecture Decision Record (ADR). The ADR captures: what decision was made, why it was made, what alternatives were considered, what constraints applied, and what the expected consequences were. ADRs are stored with the code. Future maintainers can understand not just what the system does but why it does it that way.
Principle 5: Dependencies Are Actively Managed
Dependency updates are not a crisis response to vulnerabilities. They are a routine activity. Automated tooling tracks dependency freshness. Minor updates are applied continuously. Major updates are planned and resourced. A dependency that is not actively maintained by its upstream community is flagged for replacement.
Principle 6: Sunsetting Is Planned, Not Panicked
When software reaches the end of its useful life, it is retired deliberately. Users are notified with advance warning. Data is exported in documented formats. The code is archived with its documentation. The retirement is a planned transition, not an abandonment.
5. Case Study: Stewardship at TELOSIS
TELOSIS is structured to make stewardship possible.
Long time horizon. TELOSIS brands are built for decades. Software that will exist for decades must be maintained for decades. There is no exit. There is no acquisition that will pass the maintenance obligation to someone else. The institution that builds the software is the institution that maintains it.
Small, stable teams. High turnover destroys institutional memory. TELOSIS is designed for a small team where people stay. When an engineer works on a system for years, they understand it deeply. They maintain it because it is theirs.
Maintenance is the culture. The TELOSIS Operating Manual defines stewardship as a core function: build, knowledge, steward. Stewardship is not an afterthought. It is one of the three pillars of the company.
Documentation is a requirement. Every product ships with documentation before it ships to users. Undocumented features are incomplete features. Documentation is not written once and forgotten. It is maintained alongside the code.
Sunset policy. No product is abandoned without: 90 days minimum notice, complete data export tooling, migration documentation, a public explanation of the decision, and open source release of the codebase where possible.
6. The Economics of Stewardship
The objection to the stewardship model is cost. Dedicated maintenance capacity is 20 to 30 percent of engineering time. That is 20 to 30 percent not spent on new features.
This objection is correct in the short term and incorrect in the long term.
In the short term, spending on maintenance reduces feature velocity. This is visible. It is measurable. It is uncomfortable.
In the long term, not spending on maintenance reduces everything. The system becomes unreliable. Features take longer to build because the codebase is a tangle of patches. Dependencies become unupgradable. Eventually, the system must be rewritten. The cost of a rewrite exceeds the accumulated cost of maintenance by a factor of two to five.
The organization that funds maintenance continuously spends less over the system’s lifetime than the organization that defers maintenance until crisis. But this saving is invisible. It is the absence of a crisis that never happened. It is the rewrite that was never required. It is the engineer who stayed because maintenance work was valued.
Invisible savings do not appear in quarterly reports. They appear in the long term survival of the institution.
flowchart LR
subgraph "Short Term"
A["Fund maintenance"] --> B["Lower feature velocity"]
C["Defer maintenance"] --> D["Higher feature velocity"]
end
subgraph "Long Term"
B --> E["System is reliable"]
B --> F["No rewrite needed"]
D --> G["System is unreliable"]
D --> H["Rewrite costs 2-5x"]
end
E --> I["Institutional survival"]
F --> I
G --> J["Institutional crisis"]
H --> J7. Conclusion
Software rot is not a law of nature. It is a consequence of organizational choices.
When maintenance is not funded, software decays. When maintenance is not measured, software decays invisibly. When maintenance is not rewarded, the people who could prevent decay are incentivized to leave.
The industry treats rot as inevitable because accepting it as a policy failure would require changing how organizations allocate resources, evaluate engineers, and reward work. That change is uncomfortable. It is easier to blame entropy.
But institutions that plan to exist for decades cannot afford this self deception. Software that matters must be maintained. Maintenance must be funded, measured, and rewarded. The people who do the maintaining must be valued as highly as the people who do the building.
This is not a technical insight. It is an institutional commitment. TELOSIS has made it. The rest of the industry can choose to follow.
References
- Parnas, D.L. Software Aging. Proceedings of the 16th International Conference on Software Engineering, 1994.
- Feathers, M. Working Effectively with Legacy Code. Prentice Hall, 2004.
- TELOSIS. Operating Manual v1.0. 2026.
- TELOSIS Research. Documentation That Survives. TELOSIS-RP-2026-008, 2026.
- TELOSIS Research. Exportability as a Structural Property. TELOSIS-RP-2026-007, 2026.
Citation
TELOSIS Research. (2026). Software Rot Is a Policy Failure, Not a Technical One. TELOSIS-RP-2026-013.