Technical debt, also known as tech debt or code debt is the implied cost of reworking technical problems. It’s caused by choosing the sub-optimal solution, for the sake of speed, instead of using a future-proof approach that would take longer. Like monetary debt, if not repaid, it can accumulate "interest," making it harder to fix and pay off. It’s important that your business, marketing, and IT teams address the topic together — and often — for the best outcomes possible. Keep reading to learn more, including how taking on technical debt can be a positive business move.
When to Take on Technical Debt: Sample Scenario
Technical debt is not always a negative. Sometimes it is a solution to an urgent business need. Let’s take a look at this product launch scenario, to see how tech debt can be used as a positive:
Your marketing team notices that a competitor just launched a new product aimed at gaining a large portion of your customer base. You have a similar product launching in six months, including a microsite with a product selector, interactive comparison, and self-service features. IT has estimated that the microsite and features will take three months to complete and is in their queue. But now that your competitor has launched, you need to find a way to launch in one month instead of three.
What’s your plan? The best practice is to meet with your teams, keeping the language positive and focused on solutions — not issues. In the meeting, IT explains that their tech lead is heads-down on another marketing project and that one solution is to bring in a contractor to do the development work.
After discussing, you all agree to pause the other marketing project so that the tech lead can prioritize this one. You align on the fact that you can’t adequately implement both the product selector and comparison feature in one month’s time, so you agree both will be hard-coded for the fastest solution. Everyone is aware that by taking this approach the code will need to be reworked post-launch to make adding and removing products easy.
The work is completed and launched in a month — with very few issues. By coming together, talking openly about technical debt, and considering the positives of taking it on, your teams were able to meet the launch deadline.
Questions to Ask When Considering Taking on Technical Debt
Before you decide to take on technical debt, there are many questions to consider, in order to ensure your plan makes sense for the business:
-
What will be the impact of doing something the sub-optimal way? Think about what it means for content editing, performance, and updating or adding to the solution in the future.
-
Do all impacted teams accept the drawbacks of implementing this sub-optimal solution?
-
Is implementing the sub-optimal solution necessary in this situation, or do we have the flexibility to do it right the first time—even if it takes longer or costs more upfront?
-
What is the plan to address the technical debt after we complete the initial implementation?
Actions to Take Once You’ve Decided to Take on Technical Debt
Though there are only two action items, they are essential to an optimal business outcome:
-
Make sure impacted teams are aware, so they aren’t caught off guard if risks become issues.
-
Allocate time and resources to resolving technical debt in the future. Get it documented, in the queue, and follow through.
How to Spot if Something is Likely to Create Technical Debt
Quality development takes time. Time to architect the optimal solution. Time to do quality coding. Time to do code reviews that will catch issues. If you hear words that indicate a time crunch, like fast or speed to market, or if there’s a negotiation on condensing timelines, those are all signs that you might be headed down the path to taking on technical debt.What Does Taking on Too Much Technical Debt Look Like
If coding standards, architecting tasks, and code reviews are not part of your development process, you may already be accumulating technical debt. When technical debt piles up, it shows up in the form of degrading website performance and frequent issues that take longer to diagnose and solve — because the codebase is hard to work in. You may also notice that, when you fix one issue, another one crops up as a result.
Taking on too much technical debt can negatively impact your marketing efforts, the user experience, your brand’s reputation, SEO, and paid media, and can eventually compound to the point of needing to rebuild your website from scratch. That’s why it is crucial that you make technical debt discussions a key part of your marketing and development process.