EDIT: Phrasing
At one of my workplaces we had an application that was without a formal supporter and everyone hated to touch it. After I was assigned to dive in to fix a bug, I did a study of how it got that way. I was very surprised by the results I found. Basically, two things went wrong:
* Firstly, due to some mismanagement, the local team moved away, leaving it unsupported.
* Secondly, outside code underwent some paradigm shifts, meaning that anyone who knew outside code found this code to be foreign. Often, people assigned to fix bugs/add features in this code would try to apply the outside paradigms without understanding or adapting the local conventions, creating ugly code interfaces.
Here was the part that amazed me: The time between this code being not-perfect-but-perfectly-normal and becoming ugh-I-hope-I-don't-have-to-touch-that was _6 months_(!)
We've always known that technical debt becomes a problem, but I had no idea it would compound so quickly. Granted, this was at a "post-startup" company going through rapid change as the scope of work kept increasing, but that's still a startlingly fast decay rate for code that was decently written and tested.
Definitely proved to me the value of an active maintainer.
Like if you put a soda on a block of ice outside. It will last through the winter and stay solid. Wait until spring and things start getting slippery and wet. The ice and soda are showing signs of aging. Summer hits, and your soda crashes to the ground, spills, everything is just sticky, unusable, and bugs are everywhere.
Famous last words.
Not if it calls or is called by code that changes more frequently.