I understand GP as saying that if business people know about technical debt, it means you're giving them too much details. Business people care about features being implemented and bugs being fixed; they don't (shouldn't) care if implementing a feature is 1/3 direct work on the feature, and 2/3 fixing the architecture to make the direct work on this and future features faster - but if you communicate this split to them, they'll start asking if you couldn't cut that 2/3 part out.
I mostly agree with this in theory, but there’s a tragedy of the commons problem when working on a development team. A developer who takes the quick-and-dirty route will appear more productive in the short term than one who tries to maintain long-term development velocity.
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.
I can think of a few ways of combatting this though.
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.
Yeah, I've been on a team like that, and I can only recommend either (1) leaving for a functioning team, or (2) fix your team. And I don't know how to do (2).
I'm talking about how the development team as a whole should relate to other parts of the business.
