It's an internal part of engineering work, and doesn't impact users. You can think of this as "encapsulation" if you like.
Also what it sounds like to outsiders is "we're taking time off to fix things we didn't bother to do right in the first place". And that's not *100% wrong...
This is wrong. Technical debt is almost always incurred because of the business requirements. They need to be made aware the debt is being incurred at that time so they are aware it will need to be paid down ASAP.
Example: a startup is asked by an investor for a particular feature to be implemented for a trade show a week from now. That feature - if done properly - would require a database schema change otherwise the queries will be abysmally slow. Luckily, for the trade show the amount of data being queried is small enough that it won't matter. But as soon as it starts getting used, whoa boy.
Management needs to be made aware that there is technical debt being incurred here. Yes, the deadline will be met and the show will go well. But there better be time on the schedule to do it right afterwards.
In this case I'd tell the business that we can absolutely write a hacky version for the trade show, but if they want a fully performant version later, that's a separate story, and much of the work going in to the first story will have been wasted.
Maybe we don't even disagree on much there.
The scenario I had in mind was when you decide to rework/refactor some existing code because it's badly designed because of incompetent original design, changing requirements or whatever else.
To me that's just an ordinary Tuesday, all part of the work we do all the time, and nothing I need to communicate, any more than I need for when we take a lunch break.
Maybe this is the difference between thinking of the business as my "customer" rather than my "boss".
I absolutely loathe doing this - the costs of technical debt are too specific (e.g. 2 hours a week) while the benefits are too diffuse and too hard to measure. If you have a conversation with business people about it it feels like you're having to make a business case for buying pencils.
Wouldn't "the feature gets done in 1 day instead of 2 weeks" be a very specific benefit?
It's a hard sell, and that's precisely why it doesn't get done.
If they’re working on a shared codebase together, the latter developer will end up cleaning up the mess left by the former and getting less recognition from management. In all likelihood, this developer will either leave due to resentment, be laid off for underperformance, or stop doing the maintenance work. In any case, there’s no longer anyone seeing to the long-term development velocity and the team’s productivity will slowly grind to a halt.
1) Slack in the system, meaning there is time without explicitly defined tasks that have to be done.
Basecamp does something like this where they take 1-2 weeks off scheduled work after a 6-week cycle to let their employees fix things up [0].
2) A good definition-of-done plus a technical culture focused on quality.
My current workplace has a culture of valuing correctness and quality over velocity, it has been a nice change of pace from my previous workplace where velocity was valued over everything else, leading to lower velocity as our code became worse over time.
0: https://3.basecamp-help.com/article/35-the-six-week-cycle
I'm talking about how the development team as a whole should relate to other parts of the business.