System Deterioration

Machineries need oiling after some time; building structure deteriorates due to natural forces; facades need to be repainted; the Golden Gate bridge needs to be repainted; vehicles need to be maintained; what does that mean for systems?
I’m inclined to believe that software systems, like all other things, need to be constantly maintained, oiled, cleaned, before they deteriorate.

How does deterioration look like?

Deterioration may appear in these forms:

1. systems become slower progressively
2. systems crash/ become unavailable more often
3. systems become more bloated (larger codebase, more storage space required, etc.)

The system was originally deployed and tested fine so what went wrong?

How does deterioration happen?

It typically happens due to the following forces:

1. user-base increased post-deployment to a number that was not intended/ tested for
2. smart users found ways to use the system that was not originally intended for
3. operation/ support team did not make it a point to upkeep the system
4. “quick and dirty” changes made to the system resulted in technical debt
5. data growth beyond expectation or unplanned data growth

What can be done to upkeep the system?

The following could alleviate the situation:

1. repay the technical debt (if any)
2. plan and implement archival strategies for the file system and database
3. consider data partitioning for huge tables
4. review database indices to remove old and unused ones while creating new ones where necessary
5. review the hardware capacity and resize as appropriate
6. make use of multi-threading/ multi-processing where necessary (only if such skillset is available)