Managing technical debt

We are inept at perceiving the effects of debt, we grossly underestimate compounding factors and fall into a debt trap. Debt is tempting, it gives that edge to own things which is not possible now but only with the future effort that we can conveniently borrow and buy. There is a saying in Tamil, buying something in loan is like lighting a fire with borrowed hay but to repay it has to be paid in wood for same volume. If instant gratification takes priority then debt that needs to be repaid will hit us hard and bring us to a grinding halt. Corporates love debt, because with a lower cost of interest they will be able to create a high value output. This is where debt helps, if we are able to create something that is more valuable that can repay the debt with interest and still leave us with lots of money then debt is good.

Developers take debt analogy to code and create technical debt to get features fast to production, one major drawback is that most of us don’t understand monetary debt and its impacts well even though it can be quantified; but take decisions on technical debt which is difficult to quantify.

Let us have a look at an analogy, Neo has a trash can in his area that has to be cleared periodically. Clearing the trash can whether it contains little trash or full can of trash takes the same effort, so he prefers till the trash can fills up. The trash accumulates in a way that it doubles every day if not cleared. A new person Brio takes up the place of Neo, Neo explains that the first day only a gram of trash gets generated after clearing, but if left uncleared it doubles every day. He used to clear it every 10th day as it is around 500 grams by that time.

Brio observes that the trash piling up day to day is trivial to care about, around the tenth day he notices that trash is 500 grams and barely fills the can, he decides to come back 10 more days later forgetting the fact that it doubles. 10 days later what was a small can trash turns into an unmanageable heap of mess which is about 500 kilograms. The power of compounding is too easy to miss in the initial days, it will hit us hard who are used to linear maths.

Same is applicable for technical debts in an application. Tradeoff decisions have to be recorded and visited at frequent intervals to see if it is causing any harm than the convenience it provided. Technical debt also paves way for ‘Broken Windows’. Software development is a social activity, it will be very easy to make a broken window the new norm when code changes hands. Run your tech retrospectives; review code, design and architecture as an entire team at frequent intervals, that will help to manage technical debt better. Remember, it is not like corporate debt which is manageable by numbers.