In your experience, what are the most difficult-to-quantify forms of technical debt? Examples of tech debt that were hard to identify in your system, times it was tough to measure it, etc.
Sort By:
Oldest
Sr. Director, Cloud Platform in Telecommunication3 months ago
Custom integrations can be some of the most difficult, particularly if they were designed without an eye towards portability. As Mike mentioned, dependencies are also quite a challenge. Director of IT3 months ago
Complex code can obscure issues that may not be immediately apparent, leading to unexpected outcomes. The intricacies of such codes make accurate analysis and assessment challenging. Moreover, this complexity often prevents further modifications, as developers, other than the original author, find it difficult to make changes without unintended effects. While comprehensive unit testing can be beneficial, alterations still remain a difficult task. Field CTO in IT Services2 months ago
Previous posters have all made great comments - I would add that Tech Debt is an overhead or burden you are carrying - be that a deliberate choice or imposed on you by external factors. Key thing is the impact of that tech debt (together with ways of measuring that impact).... how much faster could you build or accomodate change if the tech debt was less (easing the cost/burden of future changes - see https://martinfowler.com/bliki/TechnicalDebt.html) ?, How much future capacity/time could you free up if you addressed specific elements of tech debt now ? Are you carrying the heavy burden of custom support agreements for your legacy systems (at what cost and duration) ? Are you exposed to critical cyber vulnerabilities for longer periods of time ? etc. Tech Debt is a risk appetite decision - better to make it a deliberate and considered choice rather than have it passively imposed upon you and your organisation.CTO in Media2 months ago
I separate tech debt from "poor decisions" or decisions made without due thought and planning.You should be aware of opting into tech debt as you go.
When considering tech debt, it's like contemplating a financial loan for a specific outcome. You weigh the benefits against the costs, which becomes part of your decision-making process.
This allows you to cost the "tech debt" decision against the other options and make a case for one versus the other. Communication then becomes more grounded, as you can express time saved early on, yet clearly communicate the cost to readdress at a future time by expressing the signals that rework will be required and the cost at that time or times.
i.e. Tech debt can help you express implementing a solution now in 100 hrs, instead of the 'more robust' or 'better long term solution' which would cost 1000 hrs.
However, in the future, it will take 2000 hrs to rework.
This clarity can help technical managers and leaders engage in planning and prioritization conversations at a much more functional level.
Mike