
Software Aging (1994) [pdf] - tjalfi
https://www.cs.drexel.edu/~yfcai/CS451/RequiredReadings/SoftwareAging.pdf
======
lioeters
> Programs, like people, get old. We can't prevent aging, but we can
> understand its causes, take steps to limit its effects, temporarily reverse
> some of the damage it has caused, and prepare for the day when the software
> is no longer viable.

> A sign that the Software Engineering profession has matured will be that we
> lose our preoccupation with the first release and focus on the long term
> health of our products. Researchers and practitioners must change their
> perception of the problems of software development. Only then will Software
> Engineering deserve to be called Engineering.

\---

According to the article, there are two types of software aging: change or
lack thereof.

\- Lack of movement: failure of the product's owners to modify it to meet
changing needs

\- Ignorant surgery: result of the changes that are made

In addition, distinctly from aging, there's accumulation: "the system slow
down caused by failure to release allocated memory" or storage, file system
filling up, etc.

\---

Some of the costs of aging:

\- Inability to keep up

\- Reduced performance

\- Decreasing reliability

Strategies to reduce such costs:

\- Design for change

\- Documentation

\- Reviews

\---

How to deal with aged software:

\- Retroactive documentation

\- Incremental modularization

\- "Amputation"

\- "Major surgery" \- Restructuring

------
raister
There is also a considerable body of work on so called Software Rejuvenation,
to mitigate software aging phenomena, lead by Prof Kishor Trivedi, from Duke U

