This is Part 2 in our blog series on Technical Debt, where we explore why and when DevOps teams should take on technical debt by choice.

Technical debt can be a result of unintentional actions (“sloppy coding”), acquired over time (aging systems that need to be replaced), or conscious decisions to meet business objectives. In all cases, the decision on whether to address technical debt now comes down to the balance between opportunity costs and business value. Let’s look at three scenarios where teams must decide between acquiring technical debt, delaying releases, or incurring additional costs.

Scenario 1: Shortening Time to Market

In this scenario, your organization wants to release a new application feature that customers want. Adding this feature now would help grow your company’s revenue by attracting new customers. You are worried your customers may switch vendors if your app appears to be lagging.

In an ideal timeline, your developers would create robust, reusable modules that could be used for future requests, but it will take an extra month to develop and test that code. Alternatively, they can create a feature-specific routine that can be coded and tested in one week. The difference between doing it “right” and doing it “quick and dirty” is four weeks, enough time that your competitor may beat you to market.

In this scenario, the right call may be to take on short term technical debt to get this release out the door, and then immediately start work on the reusable solution while your sales team is winning customers.

Be careful with this decision. Frequently, all feature requests appear to be critical when they’re not, and teams who do not methodically track technical debt with concrete plans to address it will find themselves spending more effort to update dirty code.

Scenario 2: Minimum Viable Product

Whether your DevOps team is a startup strapped for cash, or an enterprise testing the waters with a proof of concept, you’ll encounter scenarios where you don’t yet have funding to create the full product “the right way.”

Teams in this scenario may choose to take on technical debt in order to delay costs until the next round of funding is won. In this case, the immediate work is required to prove viability to the investors.

Keep track of the design trade-offs to avoid issues scaling your product later. Make a plan to address technical debt when that funding comes in.

Scenario 3: Unclear Business Direction

Technical teams should avoid taking on technical debt to meet unclear business objectives. While delivering a quick and dirty version might seem faster, it will take twice as long if your team misunderstood the requirements. Get clarification, then make an informed decision on prioritizing new work versus paying off technical debt.

Summary

The decision to take on technical debt should not be taken lightly. There are good cases for taking on technical debt, like Scenarios 1 and 2. Regardless of the reasons for taking on technical debt, it must still be repaid. Track and plan when your team will address it before the interest slows down future work.

This is Part 2 in a 4-part series on Managing Technical Debt.