Ten-year-old software can be excellent
We work on applications built a decade ago that are pleasant to change and entirely fit for purpose. We also work on three-year-old ones that are almost untouchable.
The difference is not the original quality. It is whether anyone has maintained them continuously.
The habits that matter
- Dependencies updated monthly rather than annually
- PHP version kept on a supported release, always
- Tests kept passing, not disabled when inconvenient
- Decisions documented as they are made
- Code improved where it is touched, not in a separate project
Deferred maintenance compounds. Each skipped update makes the next one harder, until a routine upgrade becomes a project.
A named owner
Someone in the business who knows what the application does, decides what changes, and notices when something is wrong. Not necessarily technical.
Applications without an owner drift: nobody notices the report that stopped, the integration that failed, or the process that changed six months ago.
Change it as the business changes
- A process change should trigger a system change, not a workaround
- Workarounds accumulate and eventually become the process
- Small changes made promptly are cheaper than large ones made late
- A system that no longer matches the business is worse than no system
Budget for its whole life
| Year | Typical spend |
|---|---|
| 1 | Build cost |
| 2–3 | 15–25% annually, maintenance and small changes |
| 4–6 | Similar, plus occasional larger changes |
| 7–10 | Similar, plus a modernisation at some point |
Budgeting only for the build is how businesses end up with a system nobody has touched in four years and a rewrite proposal they did not expect.