When does it make the most sense to deliberately take on technical debt? What's your reasoning for doing so?
Sort by:
When there is a gap in timing between your longer term or modernization solutions and when the business needs something in place. You need a short or mid-term bridge until better solutions are ready, or you are enhancing legacy solutions because the cost/benefit doesn't justify the migration yet.
The caution of this is that sometimes the longer term solution / mitigation doesn't come to pass and you get stuck with debt you didn't intend in the long run.
I agree fully with Jair. The rule that I follow is to have a clearly established quantifiable business value, and a clear calculated cost of the technical debt. Then, ensuring that the quantifiable business value exceeds the ongoing cost.
That’s a good question, and I often do it in architecture and project leadership conversations. In my opinion, deliberately taking on technical debt isn’t so bad. It can be strategic, if done with awareness and a PLAN. I believe it does make sense when:
> You're experimenting or prototyping;
> Requirements are still evolving or not well established;
> Resources are temporarily limited;
> Speed-to-market is critical;
> The "perfect" solution cost is too high;
> The strategic value is high, and the technical risk is low.
You have to keep in mind that "debt can be fine", but only if you track it like a loan: with a purpose, clear terms, and a payoff plan.
It will depend on your line of business and the aplicable regulations. Also depend on the risk appetite of your business. For some industries is acceptable to take on some technological debt, for others regulation and compliance doesn’t provide much leeway.