The 3 main types of technical debt are: deliberate, accidental/outdated design, and bit rot.
Just as smart financial debt can help you reach major life goals faster, not all technical debt is bad, and managing it well can yield tremendous benefits for your company.
This is particularly true for rapidly-growing companies, who have a critical need to ship products early and often in order to determine product/market fit, meet customer needs, and seize emerging opportunities. But just like financial debt, you have to be wise about incurring tech debt. Over the long term, accumulated debt can slow your shipping speeds, cause developer morale issues, or even sink your business entirely.
Dag Liodden has been managing technical debt for over 14 years — most recently as the Co-founder and CTO of adtech company Tapad, which he helped guide to a $360M acquisition. While there’s no simple one-size-fits-all solution, Dag’s found that classifying debt into categories helps with communicating and addressing tech debt issues in and across teams. He shared the three main types of tech debt, and his strategy for addressing each, with FirstMark.
1. Deliberate technical debt
Often, engineers will know there’s the right way to do something, and the quick way to do something, says Dag. In many cases, the quick way is the right way (to avoid over-engineering), but at times the team will intentionally do something the “wrong” way because they need to quickly deliver product to the market.
“We sometimes deliberately incur tech debt to reduce time to market.”
When taking this route, consider not only how much time you’ll save on launching a feature, but also what it will take to repay the explicitly incurred debt. Make sure the stakeholders are aware that this will inevitably slow down other feature launches later on.
How to address it: Your team’s implementation of agile might disagree, but Dag has found it usually makes sense to track this type of tech debt in the backlog when deliberately deferring work that needs to be completed. If it’s not tracked specifically, it’s unlikely to be repaid and will turn into accidental design debt over time. Product owners and stakeholders should be held accountable for the accrual of this kind of debt as it’s incurred by business decisions.
2. Accidental/outdated design tech debt
When designing software systems, Dag’s team tries to balance thinking ahead and future-proofing their designs with simplicity and quick delivery. This is a tricky balance, he cautions, and nobody gets it right every time. As systems evolve and requirements change, you might come to the realize that your design is flawed, or that new functionality has become difficult and slow to implement. A good original design will often be easier to refactor incrementally, but sometimes you may have to bite the bullet and do a more significant refactor.
How to address it: How to significantly refactor a system well is a huge topic in itself, but it’s completely natural that this needs to happen every now and then (every other year or so when the system is in a “steady” state). Otherwise, you might over-engineer the system in the first place and incur unnecessary slow-downs all along. Team/tech leads and product owners should be accountable for ensuring time is set aside to resolve this type of tech debt as it’s incurred by design decisions and frequently changing requirements.
3. Bit rot technical debt
Bit rot tech debt happens over time. A component or system slowly devolves into unnecessary complexity through lots of incremental changes, often exacerbated when worked upon by several people who might not fully understand the original design. Symptoms are, among others, copy-paste and cargo-cult programming.
How to address it: This is perhaps the only type of tech debt that you should try to avoid consistently, Dag says, by continuous refactoring. Strong teams will take the time to understand the design of the system they are working on (even if they didn’t design it originally), incrementally improve the design and clean up bad code along the way. The development team should be accountable for avoiding bit rot tech debt as it’s incurred by individual developers.
While categorizing tech debt won’t magically make it easy to handle, it can enable more productive conversations and strengthen your team. Tech debt will, and should, always exist in systems. It’s essential that you try to understand how the debt is slowing your team down, and balance efforts of delivering features in the short term with increasing overall productivity in the mid to long-term.
via hackernoon.com
