I disagree. It should be only cleaned up, if nothing else is more important.
On the other, it's a statement that executive priorities mostly trump technical priorities, which I deeply disagree with. Executives generally have a poor understanding of how technical debt works over the long term: https://web.archive.org/web/20190709091156/http://agilefocus...
Week to week, many will say, "OMG, this feature is way more important than technical debt". But year to year, they will say, "Why is it so hard to get anything done here?!? Why is our stuff so buggy?!? We must have terrible developers!" Which is both a management failure and a failure of developers to maintain professional standards. The first is mostly out of our control, but the second is up to us.
And there are opportunity costs: Fixing a particular code smell means that future features of the application will get delayed. And the question is not only at what point in the future, in some (YAGNI) cases perhaps never, our now improved code quality let us catch up with otherwise earlier feature implementations: The extended time-to-market for our new features also comes at a price.
So to decide what is actually best, it is not enough to look only at the technical side of a software project. The time-to-market (or time-to-use) cost, which has nothing to do with engineering per se, must also be taken into account.
When deciding when a particular code smell should be fixed, both technical and business aspects are important: Technical effort and benefit must be evaluated and weighed against the aforementioned opportunity costs of feature delays.
That is why good cooperation and open communication between engineers and business people within a company is important. If this is not the case, well, this is another smell that perhaps needs to be refactored first. If it is worthwhile ...
Technical debt is, to me, usually half-finished work. Instead of completing the job, we accepted an 80% solution that is designed in such a way that makes the 100% solution impossible without a complete rewrite. Eventually new features always break something or take a year each. It is this drag on speed that is the interest on the debt - we pay it with our time, endlessly.
And I think technical debt is a fine metaphor, because the term gives non-technical people useful intuitions about what is normally invisible to them. E.g., they can take it on when needed, pay it down as available, declare "bankruptcy" via rewrites. And if they don't pay it down, it will consume more of the "income", constraining future choices.
It doesn’t make sense to clean everything to a perfect condition but there should be some amount of ‘keep your room clean’ level of hygiene that’s maintained
There are a lot of ways to do this, but my general preference is a black budget plus explicit "credit card" usage. E.g., the team has high standards for any new feature work and quietly spends 15% of their time every week on continuous technical improvement. If the product manager wants to break the normal standards and take on technical debt (e.g., rush have feature X ready for trade show), then you break the work into "rush to add feature X" and "clean up feature X mess". The first gets done before the trade show, the second after.
And personally, if a product manager doesn't honor the deal, I say they get their credit card taken away for a while, because they've proven they can't be trusted to do right by the team and the company.
So in my case, it works in practice.
And I'm glad you have a very good relationship with your business stakeholders, but please recognize that's not the modal case, and that giving advice as if it were is going to be bad for people with other circumstances.
There's a bit from Bourdain's Kitchen Confidential that really resonates with me along these lines:
Mise-en-place is the religion of all good line cooks. Do not fuck with a line cook’s ‘meez’ — meaning his setup, his carefully arranged supplies of sea salt, rough-cracked pepper, softened butter, cooking oil, wine, backups, and so on. As a cook, your station, and its condition, its state of readiness, is an extension of your nervous system... The universe is in order when your station is set up the way you like it: you know where to find everything with your eyes closed, everything you need during the course of the shift is at the ready at arm’s reach, your defenses are deployed. If you let your mise-en-place run down, get dirty and disorganized, you’ll quickly find yourself spinning in place and calling for backup. I worked with a chef who used to step behind the line to a dirty cook’s station in the middle of a rush to explain why the offending cook was falling behind. He’d press his palm down on the cutting board, which was littered with peppercorns, spattered sauce, bits of parsley, bread crumbs and the usual flotsam and jetsam that accumulates quickly on a station if not constantly wiped away with a moist side towel. “You see this?” he’d inquire, raising his palm so that the cook could see the bits of dirt and scraps sticking to his chef’s palm. “That’s what the inside of your head looks like now.”
Having a reasonably tidy codebase that the whole team understands well is very much like that for me.