5 ms·

In my experience, tech debt can surface at many levels and isn't always because someone took the wrong or quick approach. Sometimes it's the best option you ha

In my experience, tech debt can surface at many levels and isn't always because someone took the wrong or quick approach. Sometimes it's the best option you have at the time. This happens a lot when you have small teams working on many projects for different business units that have strict time constraints. For example our call center needed staff availability surfaced in the CRM for routing calls. This required data from the HRMS and the individual's work calendar. We knew the HRMS system was being replaced in Q4 of this year, but the project timeline dictated this feature would release in Q2. Thus we have a tech debt item added to the backlog to refactor this integration when the new HRMS system is launched. Another example that comes to mind happened a few years back. We had a product using a framework that was falling out of support. That itself was naturally emergent tech debt. When the tech debt item was finally added to a sprint, the upgrade options were to a LTS version or an STS version after that. The feature that had delayed the tech debt for so long had been refactored again for the STS. The decision was made to skip the LTS version in favor of the STS version because it would save a huge refactor in the future. However being an STS version, it necessitated another tech debt item to upgrade to an LTS version in a year.

kybernetikos 4y ago
I suppose this shows the flexibility of the term, because none of these sound like tech debt to me. Your first one is just a new requirement (to integrate with a new system) that you can see coming down the road. You didn't make a decision that took on any 'technical debt' there. Your second one is that the framework you were using fell out of support. Unless you had previously decided to use an old version because it would allow you to release earlier, you didn't take on tech debt here, you just needed to do some work to stay on a supported version of the framework. Your last example where you chose to go to an STS version instead of an LTS version might be a good example, since you made a decision that forced you to do some upgrade work in the future sooner than you would otherwise have had to. On the other hand, it doesn't seem that you took on technical debt in making that decision, if anything, your tech is probably better and less indebted than if you hadn't. Perhaps I'd say you took on schedule debt or something else there. I suspect that you work for an organisation where anything that isn't a customer requested feature is considered 'tech debt', but I think that's a too wide use of the term.
- cptskippy 4y ago
  > I suppose this shows the flexibility of the term, because none of these sound like tech debt to me. I'm defining tech debt as a decision that expedites short term delivery but creates a need for future work. The first case was deciding to deliver a product sooner while knowing that decision would create necessary work in the near future. The second wasn't properly clarified but the version of the framework in use was STS. I suppose it's up for debate if routing maintenance is tech debt or not. I'm of the opinion that it is. > I suspect that you work for an organisation where anything that isn't a customer requested feature is considered 'tech debt', but I think that's a too wide use of the term. Yarp.

kybernetikos 4y ago

I suppose this shows the flexibility of the term, because none of these sound like tech debt to me. Your first one is just a new requirement (to integrate with a new system) that you can see coming down the road. You didn't make a decision that took on any 'technical debt' there. Your second one is that the framework you were using fell out of support. Unless you had previously decided to use an old version because it would allow you to release earlier, you didn't take on tech debt here, you just needed to do some work to stay on a supported version of the framework. Your last example where you chose to go to an STS version instead of an LTS version might be a good example, since you made a decision that forced you to do some upgrade work in the future sooner than you would otherwise have had to. On the other hand, it doesn't seem that you took on technical debt in making that decision, if anything, your tech is probably better and less indebted than if you hadn't. Perhaps I'd say you took on schedule debt or something else there. I suspect that you work for an organisation where anything that isn't a customer requested feature is considered 'tech debt', but I think that's a too wide use of the term.

cptskippy 4y ago
> I suppose this shows the flexibility of the term, because none of these sound like tech debt to me. I'm defining tech debt as a decision that expedites short term delivery but creates a need for future work. The first case was deciding to deliver a product sooner while knowing that decision would create necessary work in the near future. The second wasn't properly clarified but the version of the framework in use was STS. I suppose it's up for debate if routing maintenance is tech debt or not. I'm of the opinion that it is. > I suspect that you work for an organisation where anything that isn't a customer requested feature is considered 'tech debt', but I think that's a too wide use of the term. Yarp.