> The article does the setup but fails to deliver.
Hard agree. So much so that throughout the setup I was feeling eager to share this with my own team, and by the end I couldn’t think of any reason why I’d want to do that without writing my own follow up article.
And—probably because I’m mired in the “hygiene or fitness” forms of inherited technical debt, and many of the problems of knowledge loss that entails—I’m especially disappointed that most of the focus is on how to manage and make decisions around adding technical debt. It’s framed like extant technical debt is just a foregone, effectively permanent, conclusion. All of the same classification applies even if the debt (whichever metaphor applies) is already accrued and the consequences are already in full force.
Again probably because I’m mired in inherited tech debt, I don’t see any point in sharing this with my team because we already have a pretty good process for evaluating the risks and benefits of adding debt. But we (like most orgs IME) already have trouble responding to historical facts which present the same challenges as proposed future facts. I want this article to be addressed to “so you’re trying to manage tech debt you didn’t ask for.” And maybe I should just try to write that article, but I only have a glimpse of the conclusion myself and I’m loathe to add more setup without delivery to that particular aspect of the conversation.
Hard agree. So much so that throughout the setup I was feeling eager to share this with my own team, and by the end I couldn’t think of any reason why I’d want to do that without writing my own follow up article.
And—probably because I’m mired in the “hygiene or fitness” forms of inherited technical debt, and many of the problems of knowledge loss that entails—I’m especially disappointed that most of the focus is on how to manage and make decisions around adding technical debt. It’s framed like extant technical debt is just a foregone, effectively permanent, conclusion. All of the same classification applies even if the debt (whichever metaphor applies) is already accrued and the consequences are already in full force.
Again probably because I’m mired in inherited tech debt, I don’t see any point in sharing this with my team because we already have a pretty good process for evaluating the risks and benefits of adding debt. But we (like most orgs IME) already have trouble responding to historical facts which present the same challenges as proposed future facts. I want this article to be addressed to “so you’re trying to manage tech debt you didn’t ask for.” And maybe I should just try to write that article, but I only have a glimpse of the conclusion myself and I’m loathe to add more setup without delivery to that particular aspect of the conversation.