In software engineering, there is a trade-off between feature development and maintenance. Should we devote resources to building new things or should we spend time improving code hygiene?
And in my experience, engineers will choose the first option. I won’t go into the reasons why in detail but in short, people prefer making stuff over cleaning stuff. Very understandable!
I've been thinking of ways of framing “software maintenance” to come up with strategies on how we can ensure that it gets done. And so, one of the first analogies that came to mind is environmental conservation, which is “the practice of preserving the natural world to prevent it from collapsing as a result of human activities.”1 Software maintenance is in a sense “preservation”— it involves cleaning up and refactoring the existing code base, with the longer-term goal of facilitating the development of new projects in the future. And if you go too long without maintaining your software, it becomes nearly impossible to develop.
Theodore Roosevelt, often considered the “conservationist president,” wrote and spoke about environmental conservation at length. I’ll have to research him a bit more, but for now, here is a quote from him that I like:
Conservation means development as much as it does protection. I recognize the right and duty of this generation to develop and use the natural resources of our land; but I do not recognize the right to waste them, or to rob, by wasteful use, the generations that come after us.
Software can be susceptible to “tragedy of the commons” when engineers are not mindful of how they contribute, leaving the codebase too complex to sustain any future development. And this mentality of “conservation” is especially important for large, open-source projects in my opinion. Protecting code is vital for the development of software that is stable yet constantly evolving.
https://www.volunteerhq.org/blog/best-environmental-conservation-programs/