Tackling Technical Debt
Technical debt is very common for a new company, new product, or new feature. It’s often the result of proof of concept experiments – used to determine whether some element is worth keeping around or not. Tackling technical debt requires you to, first, understand what it is, and how it’s created. There are some benefits to creating some technical debt, but if it isn’t paid back, how it can impact a business or product can be detrimental.
11 ways to minimize “Software Entropy”
There are some common ways companies are tackling technical debt. In all of them, in order to prevent a wild-west of random initiatives, they should be prioritized by the team and/or product and/or management, understanding their benefit and cost.
1. Maintain the status quo – live with the debt for now and reevaluate it in the future, determining how and when you should pay off which debts.
2. Tech work before starting a story – before starting the actual requested change, preparation work is done (usually refactoring), so that it’s easier to come up with the right design. It’s preferable to separate the refactoring from the new change because then the pull requests are smaller and simpler to review, test, and reason about.
3. Boy scout/girl scout rule – upon touching any code, leave it in a better condition than you found it. This is similar to refactoring before starting a new story but doesn’t necessitate that they are separated or complete before the requested change.
4. Sustainability bandwidth – reserve a fixed amount of time or effort each week for technical work. Whether you work in Kanban or Scrum, make sure all team members and managers are aware that there is a bandwidth for constant tech work. The number can be fixed or changing every week based on needs (can be a timebox, can be a number of stories or story points).
Some teams prefer to have a single backlog with all items, and some prefer separate ones, as long as the work selected for this week or sprint is in one place.
5. Cleaning sprints – a recurring single sprint or two, or otherwise a timebox, every 2-3 “product” sprints, that is dedicated only to tech work. Of course, incidents and major bugs still have priority.
6. Dedicated team members – specific team members, either fixed or rotating, only work on technical initiatives, while the others work solely on planned product work.
7. Dedicated teams – one or more teams that are working solely on tech initiatives, while other teams work on the product. Sometimes external (outsourced) contractors are brought in specifically for this.
8. Tech initiatives per quarter – assuming there are quarterly plans, bigger tech initiatives are collected and prioritized, and the top ones are selected to be worked on.
9. Big re-write – build a new system to replace the existing one. This can be a replacement of one module at a time, or a complete transition, rolled out gradually or in a big bang. In this category, we can find modernizations of systems, such as a move from Cobol to Java.
10. Friday Lab – more of a freestyle, timeboxed space for spontaneous smaller initiatives, or even better – make use of the time for learning.
11. Tech capital or “Inverse technical debt maneuver” – This means the opposite of technical debt. Invest in activities of R&D that will serve as force multipliers, for example, introduce an integration tool instead of custom code, automate processes for sales, or suggest simple solutions that will bring 80% of the value.
When to pay off your technical debt
We always prioritize based on the stage the company is in, the strategy and goals (building a prototype, reaching Product Market Fit, scaling), the financial resources, and the talent capacity.
The first step is to identify there is a debt. Then, it’s beneficial to collect data, hard facts, to indicate slowness or trends. Next, we need to communicate and get the buy-in of management and product and determine the most appropriate strategy to pay it back. What new features will we not work on in order to pay our debts?
We need to be vigilant for false or weak arguments, and the tendency to try out the new shiny thing without a real business value.
Lastly, after some milestones of the technical debt have been repaid, revisit the metrics and check whether things have improved. This is an ongoing process, as we continue to generate software and entropy keeps growing.
How Finiata is tackling technical debt
Initiatives that are defined as experiments can have higher debt (usually in form of design compromises or duplication, not missing tests), and when they succeed, we start paying their debt.
Existing products that already bring value are expected to have higher quality, be tested, secure and performant to serve the business needs.
Reducing your technical debt
Hopefully, it’s clear now, that technical debt or software entropy will always be part of our lives. This means we need to be mindful of it and decide if, when, and how to pay it back.
There are a variety of initiatives your development team can take to minimize and reduce and tackle the technical debt you’ve accumulated that will help you get out of the red and into the black.
