Technical Debt describes the result from the selection of a solution because it is easier at the time of implementation at the expense of the cost of doing it right down the line. This term was traditionally used in software engineering, but has jumped to many other industries. Virtually every modern solution involves a technical element (or elements), so it’s easy for a cheaper choice to end up costing more long term. It also causes entire workflows to need to be changed whenever the technical debt catches up.
The best solution for dealing with technical debt is to avoid it in the first place, though that obviously isn’t always possible. You may inherit technical debt, or have a process become technical debt due to unforeseen changes. You need to know where your technical debt comes from in order to address it. Technical debt is not financial debt, so you need to handle it a little bit differently.
Quick, Cheap, or Good
The old engineering adage goes:
Technical debt is often the result of poor choices or improper planning around these factors, though external factors can play a role. If a product needs to launch now and you have a quick solution which isn’t complete, and a good solution which will miss the launch, which do you pick? Deadlines and setbacks can often push your hand when picking which to go with.
It’s easy to say you always go with “Cheap” and “Good”, but you have to have the time to make it effective. “Fast” is also relative. The internal and external factors behind a decision as well as the scope of the task or solution dictate what’s practical. “Cheap” means two entirely different things when comparing a full ERP suite and an image converter.
What Causes Technical Debt
Making the wrong choices when deciding on a product or solution definitely sets the stage, but doesn’t necessary cause the technical debt. Most people float some money on a credit card, and that’s fine as long as it’s paid off before the month mark. The problem is when it’s not paid off and the interest is high.
Paying off the wrong technical debt can be extremely detrimental. If you focus on process reform and fix the minor issues which have low impact, you let the ramifications of the other technical debt pile up. Fixing a library which is only used in a developer tool which requires some workarounds is not going to reduce the impact of technical debt as much as fixing a bad decision which slows down the whole product. You can think of the impact as interest in traditional debt. A 5% interest rate isn’t bad compared to a credit card.
Addressing Technical Debt
There are two main fronts for addressing technical debt. The first is to prevent new debt from being formed. If you’re heavily in debt, you don’t want to go get new credit cards. The exact same applies to technical debt. The second is to reduce your debt. While Dave Ramsey’s Debt Snowball method is efficient for individuals, it needs some heavy tweaking for technical debt.
Preventing Technical Debt
Make sure your teams are organized efficiently, especially in coding shops which are known for less than stellar communication and soft skills. Internal processes need to disincentivize improper planning.
Apply data-driven or data-informed analytics. Use data to find exactly what is broken and where in the process. You can’t address what you don’t know, and you can’t just guess and follow your intuition to hit the right issue. Data doesn’t lie (when it’s actually objective).
Treat your problems like you would automation. Improper automation is technical debt with extra steps (and where a lot of technical debt shows up from). To properly automate a problem, you have to assess both its impact to determine if it is worth doing a certain way, and the cost of the automation solution. An expensive (either in terms of time or money) automation solution that solves a worthless problem is a waste of resources.
Assessing How to Pay Off Technical Debt
I mentioned the Debt Snowball method before because it is very similar to the method I use for addressing debt both technical and personal. I take into account the principle, the amount in interest, and the impact of the debt. Larger purchases tend to naturally have higher interest, but not always. Something that’s interest free or of no real importance can usually slide when worse comes to worst.
For calculating out the impact of technical debt, you need to treat these as the cost to retrofit the solution as the principle. The interest is the cost the inefficiency is having on your organization. Do you have a team dedicated to keeping an inefficient solution running? Are you investing in any infrastructure or licensing you wouldn’t need otherwise? How much time is wasted from the given piece of technical debt?
The impact is how technical debt bottlenecks the organization or teams within the organization, or the risk it creates. For instance, a choice to not sanitize input for a method which touches on a database is going to be high impact. A poorly thought out versioning system which causes changes to require manual intervention would be high impact as it bottlenecks all coding efforts.
Paying Off Technical Debt
Once you know how bad a given process is for the organization, you know where you need to focus your efforts. Work through them in the order of ease and impact. A moderately impactful item which is a simple fix is going to be an easier win than a highly impactful system which requires an entire reworking of the infrastructure.
As you get used to how to weigh various parts of the process, you can quantify this in numbers, but that requires completely understanding the organization. I convert into a financial value based on the salary and hours required, as well as an estimate of training costs, infrastructure costs, etc. amortized over the average time of use for similar products. There are probably better ways, but this is quick and easy without robust data.
Unlike the Debt Snowball method as well, you rarely want to only focus on one item when clearing out technical debt. Each team or smaller group may only focus on one item, but the combined effort means more is cleared out more efficiently. The technical people might help with part of the accounting system’s overhaul, but they won’t be of much use to the actual process change (past an assessment or technical implementation capacity). Use your new processes to prevent more technical debt in order to prevent you from messing up your old debt.
Combining the Two
In dire situations, you don’t always have the luxury of focusing on just the new technical debt before the old. A lot of companies end up in a live or die scenario due to neglecting it for so long and a lot has to change all at once. In these scenarios, it is best to focus on the most impactful of the older technical debt while shaping the future technical debt in order of ease.
You can’t just decide not to take on debt to repair your home if your house has a catastrophic issue because you still have to live there. You can choose to skip out on more “cosmetic” items (e.g. if two toilets break, fix only one first) or pieces which are too expensive, but still future problems. It isn’t ideal, but it’s better than not having a home. Don’t take on the small, easy debt and focus on the most pressing older issues.
Focus on the little things which can cause the biggest impact for new things. A $0.30 part which was never tested cost an ISP thousands of dollars because it caused larger issues. Minor process adjustments reduce that sort of waste. It took dozens of technicians to find this issue. It kept happening and happening until one went back to basics.
As you get used to rectifying the smaller new technical debt items, older things will settle and it gets easier for the organization to accept the larger procedural changes necessary to remedy technical debt. Focus on the worst cancer eating the company and prevent the smaller things from slipping by. This is a war of attrition. Sometimes you have to let a city burn to save the country.
Changing Process
Changing the way an organization responds to taking on minor technical debt takes time and effort. The issue is usually institutional or cultural, and you have to address that to address technical debt. A company which is well organized and follows process usually isn’t hit by this sort of thing. They can make the wrong decisions but they have the ability and agility to avoid the majority of the consequences of a bad decision. It’s when the bad decisions pile up that they fall.
As more solid process is implemented, it gets easier and easier to integrate more rigid, efficient pipelines. The gradual change in the organization’s response to process oriented operations makes it easier to make wider, more sweeping changes, and to have the experience from the smaller changes to do them right. If you want to climb a mountain and have never done it before, you don’t want to start with Everest.
The changing in attitude towards process inoculates the organization from future technical debt over time. Focus on the new where possible to prevent exacerbating the already existing issues. Target the oldest as a factor of their impact in process and their overall cost to the organization. With a little planning and a lot of hard work, technical debt can be eradicated eventually.
Featured image by Steve Buissinne from Pixabay