Why software needs maintenance

Software does not wear out. And yet a system nobody has touched for three years often works worse than on day one. The software has not changed; everything around it has.

What changes while nothing happens

• Dependencies. Every application uses third-party building blocks. Their maintenance ends at some point; wait too long and you face a jump across several major versions instead of many small steps.
• Runtimes. Language versions and operating systems have maintenance windows. When the foundation runs out, security updates stop.
• Third-party interfaces. Payment providers, shipping services and sign-in flows change their APIs. Old versions get switched off, usually with notice that nobody reads.
• Browsers and devices. What worked everywhere in 2021 can look different on current devices.
• Law. Requirements around data protection, accessibility and retention keep moving.

Vulnerabilities are public

The most important point gets its own section. Weaknesses in widely used components are published, which is good, because everyone finds out, and dangerous, because attackers find out too.

Once a vulnerability is public, automated scans sweep the internet for vulnerable installations shortly afterwards. Nobody has to be targeting you specifically. Reacting only when something happens means the window has already closed.

What maintenance actually means

Not "extending it", but keeping it running:

• Applying security updates promptly rather than in batches
• Keeping dependencies current in small steps
• Reacting to announced shutdowns of third-party interfaces
• Watching the monitoring and taking its alerts seriously
• Testing backups (see the separate article)
• Making sure the system can still be built and deployed at all

The last point is easily overlooked. A project whose build nobody has run for two years often cannot be put into service when it matters, which is exactly when it has to be fast.

What doing nothing costs

The effort does not disappear, it moves and gets more expensive. Twelve small updates become a migration project. A security update becomes an incident with reporting duties. An announced interface shutdown becomes an outage in production.

Changeability drops as well: anyone needing an urgent adjustment first has to catch up on three years of deferred work.

A defensible rhythm

For an average system this is enough:

• monthly security updates and small refreshes
• quarterly a look at dependencies and a restore test
• yearly a review of the runtime and major versions

That is predictable effort with a visible result, and considerably cheaper than the alternative.