|
We need more definitions. I think it's helpful to distinguish between technical debt patients and technical debt doctors. As a developer (patient), you experience the symptoms of technical debt - slow changes, dev frustration, etc. As a scientist (doctor) you observe this as a naturally occurring phenomena - with a hypotheses, measurement system and literature review. A TD doctor might be your local architect, staff or principal engineer. There's quite a bit of published literature on technical debt, which appeared quite recently (~5 or 6 years ago). One distinction is between normal technical debt (code level), and architecture technical debt a.k.a ATD (system level) [1]. So far, whether you like the term or not as a patient, it seems useful for scientists to think collectively about the phenomena in these terms. Some commenters in previous thread say an ideal (reference frame) doesn't exist, from which to calculate the delta of TD currently. The symptoms do exist. That extra few hours it takes to onboard a new developer, fix a bug or whatever are observable. If there exists a possibility to reduce that observable, measurable effort, then that possible future timeline should be the reference frame. I've risked an appeal to authority in order to transfer better understanding as a random stranger on the Internet. Technical debt seems a topic too fuzzy to fully understand, and that's why I'm pointing out the way scientists are thinking about it. I don't see any other clear path we're going to get industry wide consensus or understanding, if not for the scientific method and institutional support. That being said, the article did a good job of communicating at least 5 different ways of thinking about TD. Disclaimer: I'm building an architectural technical debt research tool called RefactorKit.com 1.https://www.researchgate.net/profile/Terese_Besker/publicati... |