Although the concept of technical debt is mostly popular within fields of software development and software architecture, the problem can be referred to basically anything that is designed, created and has to be maintained or exploited thereafter.





Part 1: Choosing a solution

Imagine you've got three friends - Bob, Eve and John who tend to borrow money from you quite often. As you begin to get confused by the number of all those small loans, you've decided to create a system to augment your memory. The decision could be pretty straightforward - let's grab a pen and a sheet of paper and start to leave a note every time someone borrows money from you. This is probably the cheapest solution, too, because the process of implementation such a system takes you about 30 seconds (open a drawer, find a sheet of paper, find a pen, write "Owe-list" on the top of the page).

Each time someone borrows money from you, you need to interact with the system by writing down a name-debt pair which takes you around 20 seconds each time (take the list out of your pocket, append an entry at the end). Those 20 seconds is an operational cost. We can approximate it is stable - despite length of the list it always takes 20 seconds to write something down.

Owe- list system parameters ========================== Preparation cost [s]: 30 (one time) Operational cost [s]: 20 (each time)









Part 2: The emergence of Debt

All right, now let's assume you've lived enough to see your friends pay you back. This time it's Eve who wishes to pay you $20 now and come back in a few days with the rest of your money.

This is a new situation for your system. Until now, you only had to write down an amount of money a person had borrowed from you and now it's necessary to deal with reimbursements, too. Sympathizing with simple, cheap solutions let's choose to continue writing down exactly the same as before but from now on, reimbursements will be preceded with a "+" sign (in opposite to "-" before debts). After Eve have payed her $20 back, Owe-list looks like this:

Naturally, as the time goes by the number of entries grows. At some point it will look something like this:

It quickly turned out, it's still quite easy and cheap to append a debt entry (nothing has changed here - you still need to find Owe-list in your drawer and write down a note which takes 20 seconds) but reimbursements get more and more cumbersome as the list extends. When handling reimbursements, not only must you write down a name and a number preceded with a "+" sign but it's also necessary to calculate how much a debtor still owes you and whether his/her debts are fully paid. Let's assume you measured the time needed to look through the records and you estimated it to be 1 second per entry. Overall, operational cost of Someone-Gives-Money-Back scenario is 20 seconds (to write down a new entry) and 1 second per each entry already exiting on the list (to calculate how much a debtor still owes you).

Owe-list system parameters ========================== Preparation cost [s]: 30 (one time) Operational cost (debts) [s]: 20 (each time) Operational cost (reimbursements) [s]: 20 + N (each time) where : N - number of entries









Part 3: Busted!

The first thing you may have noticed is that the total cost of handling reimbursements is exponential. It means a new entry makes a succeeding interaction more expensive. Eventually, you'll be dealing with a list containing hundreds of entries and each time your friends come to pay their debts you'll end up spending a good deal of time looking through their long fiscal history. This phenomenon of a system getting more expensive over the time is called a technical debt. As it turned out, the Owe-list system is heavily burdened with a technical debt when it comes to handling reimbursements.

Let's consider a little enhancement to the Owe-list system. From this point, when someone borrows/returns money, you're going to write down his/her new balance and strike off his/her previous one. This will drastically reduce the number of entries to look through when someone replays because you will only have to find the most recent entry of the currently served debtor and it will instantly tell you the current balance without any further calculations. What is more, there will be only a few non-struck-off entries at a time (as many as friends) so they will be much easier to locate. When Bob borrowed $12, you'd write "Bob - $12". When he came the next day to give $5 back and the day after to repay the remaining $7, the list would look like this:

This time, handling both debts and reimbursements requires you to find a current balance (it's rather fast as you merely take a glimpse to find a non-struck-off entry - let's assume it takes 0.1 second per each entry), strike it off and write down a new balance which is a little bit more expensive than a simple write-down action because it demands you to perform a supplementary calculation and it could take, for the sake of simplicity, 25 seconds.

Owe-list system parameters ========================== Preparation cost [s]: 30 (one time) Operational cost (debts) [s]: 25 + 0.1 x N (each time) Operational cost (reimbursements) [s]: 25 + 0.1 x N (each time) where : N - number of entries









At first, the new solution is a bit less efficient than the old one because now both operations (debt and reimbursement) contain technical debt making debt operations more expensive. Nonetheless, the above chart the cost of adding a new entry when there are already 50 of them on is by average significantly lower. This is valid only by average - asserting there are as many debt entries as the reimbursement ones. If your friends only borrowed money from you, this solution would get more expensive than the old one as the time went by. However, looking at the picture of the Owe-list, it could be observed that your friends give money back almost as often as they borrow it so it's reasonable to assert the average cost. According to it, the operational cost of the new Owe-list system gets less expensive over the time than the old one, thus the new one contains less technical debt the old one.





Summary

Every solution is burdened with a technical debt - even the first of the examples in which we merely had to deal with people borrowing money. Although the cost of adding a new entry was believed to be constant, in reality the sheet of paper being used as the Owe-list would be limited. At some point, you would have to find a new sheet of paper and endure the preparation cost once again. Like before, every entry makes following interactions more expensive but existence of the technical debt is hidden and its impact on the project is delayed in time.

The above graph reflects quite nicely how a technical debt is visible in the real life. It can be tracked by observing differences between estimated effort and actual time spent on a task. The procedure of adding a new debt entry is designed to be constant and it would be estimated so when planning tasks. However, its implementation (usage of a sheet with limited space) generated the technical debt. It could be reduced, for example, by using a computer to create the Owe-list. Despite comparable effort at the beginning though, if you wanted to rewrite everything once the Owe-list is full, it would cost much more than the interest rates of system's technical debt. After the second peek, the optimization cost would be twice as big. That's the evil face of Technical Debt - a part of it can be predicted beforehand, during a design stage and planning but the rest will surely appear down the road - when it's not really easy to optimize it anymore.

That's why the matter of technical debt optimization is more about technical debt management. When managing a project, you need to be aware of both accumulated and expected technical debt and take appropriate decisions - to either optimize it, keep it within the system or deliberately generate it. Although the last one may seem a bit odd, sometimes it's also a valid solution (for example - when dealing with limited preparation budget, aka PoC/PoV) but it's a great topic for a next article.

Hope you enjoy, don't hesitate to leave a comment!