Continuous Obsolescence
It's simple: look at what's new and right in technology, and adopt what was new at least a couple of years ago. Or don't adopt it, but do so consciously — understanding what will happen to your code next.
A special case of obsolescence is when a component loses vendor support and the development team ends up providing support themselves. That's even more fun than just working on an old technology.
It ends either with the system dying of old age and becoming unnecessary, or with a refactor that looks more like a rewrite from scratch.
Symptoms
- The project uses technologies that are already end-of-life or about to be.
- The vendor doesn't respond, and you have to "fix" things yourself.
- New hires can't get anything done: no documentation, no community.
- Every planned upgrade turns into a rewrite.
Example
The "bad" version: a service on a component that has been EOL for a long time, with "patches" from the team:
# uses the xmllib component (removed in Python 3)
# the team maintains an internal fork on its own
from vendor_xmllib import parse # internal fork
The "good" version: a conscious choice of a supported tool:
from xml.etree import ElementTree as ET # built-in, supported
How to fix it
- Keep a registry of used technologies with their end-of-support dates.
- When choosing a new technology, look not at how "new" it is but at its support and prospects.
- Plan migrations in advance, not when support has already ended.
- If a migration is inevitable and looks like a rewrite — do it consciously, with characterization tests.