This post was first published in its entirety on CoderHood as Software Maintenance, Understanding the 4 Types. CoderHood is a blog dedicated to the...
For further actions, you may consider blocking this person and/or reporting abuse
Looks like what I call "technical debt" is federated in those buckets.
I distinguish between internal technical debt, versus external technical debt.
Internal technical debt is "we took some shortcut so we could ship, but as a result the code in that area is a mess... if we're going to keep this code going forward we HAVE to address it at some point in time". Hmmm, Predictive: cost of not doing?
External technical debt are things like "The OS changed on us, Windows now requires XPS for printing, and macOS deprecated all the FSSpec and FSRef APIs in 10.8" or "C++17 is out, and most of our code is still C++98". Hmmm, Adaptive: triggers - changing landscape?
Great post. I'd say preventive and perfective maintenance have overlapping goals. I'd bucket refactoring under both. You refactor to make future changes easier. That's adaptive but also perfective since it improves the software in some way. And it is preventive because it makes it easier to perform future changes without introducing new bugs.
How you categorize your changes is less important than being conscious of where you are spending your time. As you say, when you spend a lot of time firefighting you need to step back and figure out if there's a better course of action.
It's easy to get stuck doing a lot of maintenance without seeing the bigger picture. The fate of most succesfull software is that eventually the accumulated engineering effort is mostly spent on maintenance. Some studies I read in the early 2000s suggested that most big IT projects see upwards of 60% of their budgets eaten up by maintenance. This is a sobering thought if you are doing a greenfield project (which is fun).
My view is that maintenance problems pile up and become an obstacle to necessary adaptive maintenance. When certain changes become hard or impossible, this can result in software being decommissioned. That too is a common problem with many software projects. Many projects do not survive their first birthday.
This also means that if you know you are working on something that only has short term relevance, maybe over-engineering it in an attempt to perfect it is not the right way. Quick and dirty is not long term sustainable but it can get your results quickly.
Great to see you writing again! Adding this to my reading list to read over lunch. :)
Thank you! Yes, I did take a writing break, but I am planning on starting my writing routine again. I definitely missed the dev.to community. I also realized that writing is like coding, and you do get rusty. I'll need to shake some rust off my keyboard :)
Another great article Lorenzo. You have a way of putting the abstract into concrete understandable terms. That ability is very much appreciates. Looking forward to the next one!
Thank you, David! You just made my day :)
Welcome back! Great explanation :)