Normal Debt #

Like any kind of debt, you assume it for a particular reason. Maybe you can’t afford to buy that car outright, but you’ll be able to afford it over a period of time; so you take on debt, buy the car, and you pay it back over a period of a few months.

Like any kind of debt, it can come in various forms. Maybe you left some work until the last minute, so you’ll have to stay up all night and pump out the document; so you pay it back in the form of suffering and misery for two days.

Like any kind of debt, it can become a boon or a condition. Maybe you took on debt and you bought your car; you successfully paid it off over a few months so now you have a car you otherwise wouldn’t have been able to get, and you no longer have debt. Maybe you were up all night and produced a ‘kwality’ document which your manager doesn’t like so you have to do it again. Now your document is late anyway, and you have to do it again. Also you’re really tired because you stayed up all night. Now you’re sick because you threw your body clock out of whack. Now the document is even later because you’re taking time off. Now you fail a KPI of delivering that particular document, so you lose your bonus. Owies.

There’s perks to be gained from taking on debt, but if you’re not prepared then you might inadvertently be risking a lot.

All debt functions in similar ways, except Technical Debt.

Technical Debt #

Technical debt is just straight garbage from the start. There’s no potential boon, you just end up with problems later on. The project limps along delicately before collapsing, people who had no say in the matter get blamed, and nobody is happy anywhere. Nobody seems to know how to take on technical debt and then pay it back responsibly. This happens because whoever calls the shots doesn’t seem to know what technical debt is from the get go, but they’re happy to take it on.

With enhanced accuracy and mitigated emotion; there is a lack of knowledge and understanding around the impacts of taking short cuts when things are being built. This lack of knowledge applies to the whole human resource stack - from owners, C-Levels, to managers, and technical staff. That’s not to say nobody is doing it right, but there’s a distinct lack of understanding around how to take on, and repay, technical debt.

Manifestation #

My view is predominately from infrastructure, however technical debt is typically applied to software - the project design is sound, but problems occur during implementation. Be it technical, or even if the timeline gets pulled closer due to ‘business reasons’, this is a problem. Decisions get made to make adjustments and certain things simply become unachievable and dropped. This happens, we know it will happen. We can cater for it by taking on technical debt.

This is where badness starts to manifest because the adjustments are not catered for correctly. The adjustment is made and everything keeps pushing on, just keep building. You start to hit other things that need to be adjusted due to the previous adjustment. This continues. Once all the tasks are completed, you have a thing. It’s not what it was designed to be and sure, it works (kinda), but it’s not what was agreed upon. Any documentation hasn’t been updated, it’s kind of correct but not really. The thing is stable and runs, we just need to restart this part every few weeks for some reason. Then everyone moves on, adjusting the thing only when it stumbles every now and then.

Abomination #

Over time, people have been poking and prodding to make sure the thing keeps running. Sometimes more features are delicately placed on top. The documentation gets inaccurate at in incredible rate. Only a select few people know how to keep the thing going. However, it’s no longer a thing. It has been festering and gurgling away; it has become an abomination.

Sometimes the abomination explodes, and everyone gets covered in a toxic goo. There’s precise documentation on how to dissolve the goo, but the documentation wasn’t accurate so now you just have a different kind of goo burning you. Everyone is flailing and screaming because there’s this goo hurting you, but your instructions to fix it just made it a different kind of hurty goo. After a little bit of this, someone figures out how to patch the hole in the abomination, and properly get rid of the remaining goo. Everything is terrible. This is when everybody realises the solution is garbage, and something needs to be done about it. Whether or not anything happens is another tale.

This is the payment technical debt seizes from you when you have not been keeping up on your repayments.

Responsible Technical Debt #

To be able to successfully leverage technical debt, you need to know it’s being taken on. You also need to know how you’ve taken it on, and how you’ll need to pay it back. By discussing, documenting, and actioning the technical debt, we can mitigate the risk associated with the debt, and hopefully reap the benefits of it. The debt needs to be discussed so it’s understood how it will affect other aspects of the project, the consequences of the adjustments, and how the debt will be repaid. Once it has been discussed, it needs to be documented and tracked.

Upholding the repayments is often one of the more difficult parts as “the thing is running fine, why change it”. However, the changes have already been slated and resources estimated when we documented our debt, so it’s just tasks to make sure everything continues to run properly. This way, you never end up with an abomination. In fact, you didn’t even end up with a ’thing’, it’s actually the system that you set out to build in the first place.

In order to achieve this, everyone needs to know and understand what technical debt is, and how it can be used. A lot of the people involved in the project don’t need to know the intricacies of technical debt, just a basic awareness of what it is and how it works at a high level - like what has just been outlined. Other people within the project need to understand it more thoroughly so they can work with it, make informed decisions on how to proceed, and how to manage and repay the debt that is taken on. When the project team have knowledge and understanding around technical debt, systems can be built properly. The end result is a system that is harder, better, faster, stronger.