> Don't just try to pay the technical debt off, but embrace and dig beneath. Dig into the problems , conduct customer interviews with stakeholders, get more dat

> Don't just try to pay the technical debt off, but embrace and dig beneath. Dig into the problems , conduct customer interviews with stakeholders, get more data, and validate solutions early. Good luck with that. This won't work in most situations, because the people involved have moved on or are too busy to talk to you about something that will only benefit you, but not them. Most non-software engineers won't understand the argument of development velocity in the context of technical debt. The thing that makes technical debt so miserable is that you are usually lacking context. Code comments can make a huge difference here. If a developer has to cut corners, the reason for the bad code has to be documented. Otherwise it is hard to judge if the code just looks bad but is actually fairly optimal, or if it is actually bad and a rewrite is encouraged.