I Love Technical Debt

I’m pretty sure we all know what technical debt is, attributed to Ward Cunningham in 1992, it basically states that there is no free lunch.

aws.amazon.com

But I love it. It makes us ship things quickly, validate them then refine them later. It simply makes us move fast(er). Without it, we would be slow even in situations where we can easily be faster, where we can afford to break things and take shortcuts.

Of course, this is totally dependent on the thing that we build. If we are building medical equipment, software for the aircraft, or something similar where a consequence is a human (or some other creature) life, then for sure we can’t tolerate being in debt. But more often than not we build things that will not kill someone if we implement something poorly or take a shortcut, and in this context creating technical debt can be beneficial for us. And this comes only with one condition, to pay it off regularly, to make it like we get a loan from a bank. As soon we get the money, we start paying it back piece by piece.

The thing that I don’t like about tech debt is when it’s is being neglected, put off that long that it becomes part of the design (and you know how good that design is). Another thing I also don’t like is when it’s not being neglected, it is mentioned on an almost daily basis, it is complained about,¬† but nothing is done to deal with it, instead, it just gets piled up. But the thing I almost hate is when tech debt is not neglected, rather it is well known, it’s complained about but the manager/PO gets all the blame. It is management that doesn’t allow us to clean it up. I, personally think that is a lie. Management does not have to give anything in that regard, the manager is not responsible to think about it. We, as professionals, are fully responsible. We (and only we, the developers) need to make sure, when we introduce tech debt, to document it, track it, make it transparent and clear with management, and clean it up. And it has to be a continuous process. We more-or-less introduce tech debt on a “sprintly” basis, we need to clean it up the same way. Not six months from now. Sure, I know there are environments where you are actually only allowed to ship shit, nothing better than that (and you patch/fix/make excuses and stress about it later), but if that is the case, then get the hell out of there.

An important note as well is that we, as professionals, can not simply invoke technical debt as a magical term to our management and think that is enough. Nobody likes that and that is one of the reasons why it is hated by our POs and higher-ups in general. It can be so vague with no clarity of the benefits of investing in it. We need to provide data,  we need to be clear (and be clear with it from the get-go) of the problems we are facing now and where we want to be so we can, as the end goal, reduce the overall costs or improve our company KPIs in some way.

Technical debt can be our allay (if we can afford it), but we need to be disciplined with it, treat it with respect and deal with it before it becomes our worst enemy.