I've seen it said that in any ongoing work on a large and complex software product, about 20% of the time is spent on upkeep just to keep the system from degrading further. Probably your team was already spending a portion of their time shoring up the worst parts. That's typical, and why the build up of problems slows down feature work.
I always plan on spending some percent of my time on work I know I'll have to do before I can start adding the new features. Regardless of how I'm asked to estimate, I keep in mind the cleanup work in accounting for the total effort.
Unfortunately there are still a lot of PMs and folks, including some programmers, who aren't aware of or don't understand the need for structural maintenance. Those are the teams I regularly see start out going very fast but within a few months get bogged down in having to work in the awful system they built.
Story old as time. Management typically prioritizes features over other types of work. If your ENG dept has weak leadership it becomes daunting to fight for the 20% required for maintenance of the system.
Then at some unknown point things slow down in a noticeable way and everyone scrambles to fix the slow down without fixing the culture that lead to it, and that’s if you’re lucky.
Somehow in management eyes rewrites are more palatable than refactors despite costing 10x more
There's also a psychological component for the devs. Asking me to fix your trash heap? Bye! Asking me to rewrite your trash heap? Sounds fun.
In all of these discussions about reinventing/rewriting/reimplementing already solved x, people forget that other people aren't interested in maintaining something where the fun, education, and impact was already had by the people who came first! They want to have their own fun, education, or impact.
Pretty much every conversation that starts with an angry "this has been a solved problem since such and such genius from the 70's did y" is born from misunderstanding what drives people to do anything.
I usually tend to do the refactoring without asking permission. Just spend 20% of my time on it, get it done, definitely pays off. I tend to be pretty productive generally and with this refactoring I'm not doing something like saying "give me a week to refactor from X to Y", instead I just do a little bit every day or two, so I've never had much problem with this from management.
If you're delivering features quickly it shouldn't matter if you spend some of your time making sure you'll be able to continue doing so in the future.
> Somehow in management eyes rewrites are more palatable than refactors despite costing 10x more
In part, it is resume-driven development. Rewrites are major projects, and running them (and the associated scale and budget) looks good on a management resume, and provides a nice accomplishment item.
In part, its the short-term incentive to be seen to do more with less, and move on before the consequences bite (this is also a kind of resume-driven motivation, though its more resume-driven development avoidance.) You defer work on anything but visible features, and do those in the quickest/cheapest possible way that will work in the short term, and use the credit for efficiency to move up and out before the deferred maintenance catches up. When it does, someone else gets to do a resume-enhancing big replacement project, since the state of the app makes fixing in place seem impractical. (Ironically, even with deferred maintenance, incremental remediation would probably be quicker, more efficient, and less prone to major timeline and budget-busting surprises, but when it has gotten bad enough, even the technical people who might recognize that will back management’s desire for a complete replacement because they don’t want to have to deal with the legacy mess.)
I always tell the young devs that they shouldn't ask for dedicated refactoring time but it's just part of professional development. You have to trust that using good practices consistently will help you in the long term and actually speed up development.
If they are having to touch that old code to add new features, fix bugs, migrate to a new context (say, OS version), or improve the performance/memory usage/responsiveness, then they should be improving it. Whether or not the developers are "given" time, making the change will take the time. That time can either be because the system is bad and making changes is hard, or because the system gets improved to make the changes possible.
I always plan on spending some percent of my time on work I know I'll have to do before I can start adding the new features. Regardless of how I'm asked to estimate, I keep in mind the cleanup work in accounting for the total effort.
Unfortunately there are still a lot of PMs and folks, including some programmers, who aren't aware of or don't understand the need for structural maintenance. Those are the teams I regularly see start out going very fast but within a few months get bogged down in having to work in the awful system they built.