The point behind tech debt metaphor is that you have to pay a price if you take short cuts i.e. intentional tech debts or make mistakes i.e. unintentional tech debts and the overall price of not handling these short cuts and mistakes eventually multiplies with time.
The difference between tech debt and fiscal debt as we know is how much the debt costs today can easily be totaled and the interest can accordingly be calculated and paid in the future. But, tech debt is a little fuzzier. You really can’t make out how much debt have you taken up- because you may undergone unintentional technical debt and you wouldn’t have any idea about it. Thus, you cannot quantify how much will it overall cost you and how much interest you’ll have to pay for it.
Speaking about technical debt in this manner is good, but now you need to stop pretending that they are hard numbers. The numbers are precise but quite arbitrary. It is assumed that tech debt can be calculated by equipment while looking at the code structure. In short, dealing with this debt isn’t simple and straightforward.
Image Source: Pixabay
A point to be noticed is that if technical debt is so fuzzy to be measure with regards to cost, how do you know what type of problem is creating troubles for you and how can you find out it has surpassed the limit. You need to know the different types of tech debt and how much they may actually cost you.
Making a basic mistake with regards to the architecture or platform technique
You cannot discover this until you’re too late or you have real clients using the software that you find out that a specific piece of technique such as database or messaging spec isn’t working or you have designing some basically wrong assumptions on how the system should work or how the clients should use it. And now you have only one option to start again or at the least rewrite a big piece of the system to make it work and you do not have enough time to do it efficiently.
Error prone coding
Every program has 20% of code where around 80% of bugs are seen. Thus, all big systems have a little number of routines where problem and bugs nucleate. The coding is difficult to understand, costly and hazardous to change because it was written poorly in the first place and it went to worse over time due to the clustering of small fixes and amendment.
The system cannot be tested easily
Due to the lack of automated testing or slow testing, the system isn’t easily tested. Testing costs add up to over half of the total expenses. Sometimes testing can also take much time and cost more than fixing. The cost of testing rises over time.
Consolidating technical debt is very important in order to make the system a big success. Just like the arrears of credit card bill pile up and become a problem, tech debt too shouldn’t be allowed to accumulate. People consolidate credit cards to get rid of credit card debt, similarly, they can consolidate tech debt to get rid of it!