Tech Debt might be a valuable tool
Tags: codequality, architecture, techdebt, practices
Published: 2019-10-22 19:51:05

> This post is a translation from a post I published on Medium in Brazilian Portuguese in Jul 2018. You can read it [here](https://medium.com/@joaolucasluc/gerando-valor-a-partir-de-dívidas-técnicas-22ba6d631f1).

If you're a developer, odds are you are thinking I'm crazy judging from the title of this post. But hang on, I'll explain further what I mean by that.
 
In the software development community, we got used to demonizing the idea of tech debt, which frequently blinds us for the real impact (both positive and negative) of our actions.

Usually, people don't write bad code on purpose. Bad code appears when are forced to take certain decisions or prioritize certain things to the detriment of the quality of our code.

The name "tech debt" itself comes from a metaphor by [Ward Cunningham](https://pt.wikipedia.org/wiki/Ward_Cunningham) (developer of the first wiki, one of the first proponents of the Agile Manifesto and who's a great reference in the software community in several aspects). [Here](http://wiki.c2.com/?WardExplainsDebtMetaphor) he relates the way a bank loan works (that is, the way a cash advance helps us perform certain things faster in exchange for paying fees in the medium-to-long term) with how we add complexity, bad code or less-than-optimal architectures in exchange of other priorities.

This metaphor works well because accumulating tech debt works almost the same as loans. At first, you have the benefits of leaving "dead weight" behind e moving fast (_and maybe breaking things? :P_). Afterward, you will have to pay the interest on top of this loan: either paying it all at once (and paying less interest) or little by little (accumulating this debt and leaving it to slowly grow with time). Your tech debt can usually be paid right away as well, more easily and straightforwardly or be paid progressively (with the added complexity of other things competing to be your priority).

> Oh! Does that mean tech debt is truly an evil thing, then?

Well, yes and no! Tech debt is like a little monster waiting to come out and bite you. One moment it is quiet and compliant but if you don't keep an eye out, it will become a little monster and attack you!
  
![Jack Jack from The Incredibles transforming and attacking his father](https://i.imgur.com/ovKLUXU.gif)

Have you done or do you know someone went deep into credit card debt? It is the same with tech debt! It must be repaid, one way or another!


Well, I think this relationship between real debt and tech debt is clear. But how can we positively use tech debt, the same way we can use a loan positively? *Planning to use and repay it wisely*! Let me give you some practical ideas and questions I usually ask myself to at tech debt in a smart way:  

## 1. What will I be able to achieve by accepting this debt?
Nobody in its right mind takes $10.000 in the bank to buy popsicles with all of it. Almost the same way, tech debt shouldn't be taken for any reason. Will this help you honor a critical deadline? Fix an urgent bug? Or are you just trying to ship faster _"just because"_? The response of this is crucial to decide whether or not to take a "technical loan".

## 2. What effect this will have on my users or customers?
How will we be affected by accepting this debt? A new bug every week? Will your support pipeline end up clogged due to this? Will this debt be restricted, affecting only a couple of clients? Will it be global and affect everyone? How severe will this impact be?

## 3. What's the impact of this in your or your team's future?
Leaving a tech debt in your codebase can start a snowball effect that can (and possibly will) mess up all your planning for next sprints, goals, and deadlines. Can you afford to deal with these impacts? The weight a tech debt has on a core feature is usually different from what it would be on a feature that is rarely used or one that hasn't been launched yet.

## 4. How hard will it be to fix it?
Depending on the scale of the "technical subterfuge" needed, the effort to fix it in the future will be much greater than doing it the right way in the first place. Nontrivial refactoring, unexpected bugs, dealing with abstractions created by others on top of the tech debt are just a few examples of things that can turn into more headaches rather than benefits. It's not always possible to choose. It is not always possible to choose, but if you can, it is better to give it some thought.

## 5. Is it possible to pay this little by little?
Taking a loan not knowing if you'll be able to repay it is madness, and the same applies to tech debt. Knowing what needs to be done is the first step, but planning is needed. For example: if you earn $3000/monthly but you have $2800/month in debts you'll never stop buying food or paying rent to pay these debts. Use time wisely and plan to pay this debt with caution. Remember: every day you spend repaying tech debt is one less day you build new things and move your project forward.

## Wrapping up
You can't always sweep things under the carpet, neither can you keep your credit card debt growing _ad infinitum_. The time to wash your dirty clothes always comes, so it is better to prepare wisely so you don't get strangled by tech debt.

These ideas I presented are only a few broad questions that can be a starting point to create your own priority ranking and aid decision making.

I hope they be as useful to you as they have been to me!