Definition of Debt
- something that is owed or that one is bound to pay to or perform for another: a debt of $50.
- a liability or obligation to pay or render something: My debt to her for advice is not to be discharged easily.
- the condition of being under such an obligation: His gambling losses put him deeply in debt.
Debt. This is what dictionary.com has to tell us about it. In its essence, debt represents a liability and an obligation towards someone. Something that we must return back to the debtor at some point.
Assuming we are a good Lannister citizen (something quite rare I would say), and always pay our debts as we should, we contract a loan and pay back every penny over a course of time. Our original debtor, the Iron Bank, is happy because, in the process, it will have profited via interest. Ideally, they maximise the return on investment that they make, by finding the optimal duration of this loan with an interest rate that suits them best.
Let us now imagine that we did not pay up our original debt entirely. What do you think the Iron Bank would do should we ask him for an additional loan? Do you think it would be granted straight away without a proper credit check? Would they question not whether this Lannister is able to support the additional interest and pay both loans in full still in his lifetime?
By following this train of thought, the theoretical notion of debt is not necessarily a bad thing. A Lannister gets his money and does whatever he wants with it, granted that he has paid back everything in full by the due date, and the Iron Bank is happy because it gained interest over the money that was lent. I think the same concept should directly apply to Tech Debt.
Tech Debt is not necessarily a bad thing per se, as explained by Robert Martin in his article about the subject . It is a good way to achieve a minimum viable product (MVP) in a quicker fashion.
Imagine that Mark the Manager takes the decision of contracting tech debt in order to have his product ready on time. Shortcuts are taken by David the Developer to ensure the target deadline is met and life is peachy. The product gets released, there is a big party, and a new feature for this product is envisioned by the product team shortly after.
“Let’s get an MVP for this new feature going!” – says Mark the Manager.
“But we haven’t fixed any of the tech debt yet!” – replied David.
“We do not have time for that now… We will fix it later.” – replied Mark.
How many times have you heard something like this? That there is no time to fix tech debt. Or that you will only fix tech debt whenever a certain metric that measures the amount of debt in your backlog is reached?
I want you to pause for a second and think what would happen in Game Of Thrones (or in real life for that matter, minus the life threatening consequences). Unless you prove to the debtor (bank) that you either earn sufficient funds which will ensure that you will pay back an original loan plus interest gains, do you really think you would get another loan? Well, you might, but then you are perhaps getting money from loan sharks which just want to ruin you. But no one in the software industry, within the same company, has that role, to see that you are unable to repay your tech debt.
But because software can very easily masquerade everything as being really effortless and quick, tech debt is no exception. There is no regulating entity, a central bank of tech debt if you may, which can dictate whether or not you can contract any further loans without ever paying any tech mortgage. This is precisely when Mark the Manager signs the pact with the devil and wishes to create further debt.
You may have addressed some tech debt issues in a couple of stories, but if you haven’t fixed everything, you are still left with some mortgage and interest to pay back. The problem is then easy to see. Whenever you contract more tech debt, without ever fulfilling your initial tech mortgage, you carry over the tech interest that you previously had and add that to the newly created debt.
We can see in this graph from Henrik Kniberg’s post on Tech Debt , that, over time, although some of the tech mortgage is paid back, it never is paid in full (that is a very rare case, and if this happens in your team: Congrats!).
Therefore, the rule of thumb should be to always return to your Debt Baseline, something that I have also found that never really happens, or never really happened to me. Debt just keeps piling up until it becomes unbearable. When that time comes, there is a grace period where developers work on fixing the accumulated tech debt, but are only ever expected to go to the point where things are bearable thanks to the presence of tech debt stories in Sprints/Kanban boards. What this means is that we never really reach the baseline, we are perpetually above it.
And once again, because there is no one controlling the cyclic increase of tech interest, which is a liability and obligation to be paid back as per the definition of debt, management just takes for loan after loan after loan. If this was real life, you would have the debt collector knocking on your door! And if you don’t have the money to pay up, you will lose your assets to make up for it!
Instead of thinking that tech debt is this bottomless bag of developer tricks that can bring your product to life in a blink of an eye, consider the decision of creating debt an unhedged call . Successive calls this will generate:
- Increased code complexity
- Higher degree of maintenance
- Higher coupling between components
- Slower CI/CD
- Dubious testability
And what do all these share in common? They all increase development time. Therefore, more time required translates to higher cost, or less profit in the end. To quote Frances Lash on the matter,
Therefore, even if it is more expensive to do things clean from the start, it would also be less risky. A messy system is full of unhedged calls that can be called upon at an unpredictable cost to the organization.
However, because we are all responsible Lannisters here, we pay our debts. We contract a tech load, and thus have the obligation of paying up our tech mortgage.
Tech mortage is no more than the obligatory payment of your tech debt during the epic in which you build your product or feature. And just like a real bank, you can only contract more tech debt after you have paid enough of your mortgage or interest from the original loan. IF you have not done so, then your developers, not the product team, should have the right and power to decide what is the tech debt baseline and refuse to contract more debt until that criteria is met to some degree.
Some of you must be saying that it is ok to create tech debt to meet a deadline. Let me say that I completely agree with you. However, the problem is when you take successive tech loans without ever repaying your previous debts, never going back to the baseline. Not only will this make your codebase a deadly warzone for your developers (see Spaghetti Code and Walking through a Minefield Anti-Patterns ), but will also cumulatively increase the expected time until the release of the next MVP due to all the shortcuts that were taken previously.
Thanks to Hugo Silva, Sebastien Varlet, and Geraldo Nascimento for the healthy exchange of ideas on the subject.
- A Mess is not a Technical Debt, Robert Martin (Uncle Bob), 2009 – https://sites.google.com/site/unclebobconsultingllc/a-mess-is-not-a-technical-debt
- Bad code isn’t Technical Debt, it’s an unhedged Call Option, Frances Lash, 2014 – http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-debt-its-an-unhedged-call-option/
- Good and Bad Technical Debt (and how TDD helps), Henrik Kniberg, 2013 – http://blog.crisp.se/2013/10/11/henrikkniberg/good-and-bad-technical-debt
- Design Patterns Explained Simply, Software Development Anti Patterns, 2017 – https://sourcemaking.com/antipatterns/software-development-antipatterns