One of the biggest challenges for any team is the payment of technical debt. Part 4 of our series on twelve-factor DevOps looks at what constitutes tech debt and how it impacts processes.
Factor 4: Budget
In the mission to deliver value to customers, you must not neglect technical debt. Tech debt is not just sloppy code, and it’s not a missing feature or a bug. Tech debt is anything that makes it harder for the team to maintain the code or processes moving forward. It hinders progress and will ultimately slow you down by requiring rework.
- Tech debt can come in many forms, including:
- Outdated libraries or tools
- Ignoring infrastructure maintenance and upgrades
- Choosing a fast/easy solution instead of an objectively better but time-consuming one
- Sloppy code
- Poor documentation
- Manual processes
Now that we have something of a grasp on what tech debt is, let’s consider the types of it out there. Debt can largely be categorized into three buckets based on how it arose.
Intentional tech debt is the most common type encountered in a DevOps culture. A conscious decision was made to get value to the customer faster, so the “wrong” solution was implemented. This debt needs to be recorded in the backlog as soon as it’s created, ideally during story refinement. Stakeholders and product owners must be made aware that it will eventually slow down future releases. They must also be held accountable for it because it was created explicitly on behalf of business objectives. Failure to backlog it (thereby losing sight of it) risks it turning into the second type of debt.
The second type of tech debt is accidental. This often arises from designs or processes that have become outdated, were flawed to start with, or through requirements that change too frequently. A prime example is debt incurred due to the evolution of processes. With the new method established, older processes are considered debt until they’re brought up to date. A conscious decision to create the debt may not have been made, but now it’s here.
Both intentional and accidental tech debt is somewhat easy to deal with as long as you set aside time for them. In many cases, a minor refactor may be all that’s needed to address the problem and clear the debt.
Finally, there’s entropic tech debt. In this case, the code becomes unmaintainable due to overwhelming complexity, long periods of incremental change, and large numbers of individual contributors. Out of the three, this is the worst type to deal with since it often requires a complete rebuild or replacement to pay down. You can avoid this type of debt by paying down the first two and ensuring that all contributors understand the overall design.
Paying down tech debt has several benefits. It makes the code easier to maintain overall, improves stability, and it increases the velocity of future deliveries. If you are not budgeting time in the schedule to find and pay down your tech debt, it will catch up to you.
A smart starting point is to flag debt stories in your backlog, and reserve 10% of your time for working on them. If your project is heavily in technical debt, you may need to devote more. If you find you have little debt, congratulations, you can reclaim that time for working on new or improved features.
