While economists are worried about the world economic debt (close to $260 trilliion or over 330% of GDP), it is very strange that the IT industry is not taking its Technical Debt seriously enough. Technical Debt is one of the greatest problems in IT today, and there are a lot we can learn from its financial debt analogue.

Technical Debt is like any form of debt. We borrow resources from the future to use them today so that we gain an advantage over competition. At the same time, we postpone the cost of paying out the debt to the future. Some economists call it “kicking the can down the road”, because we are not essentially solving problems today, but only postponing them and creating future obligations for ourselves. In a way, we limit our freedom to move in the future.

Is Technical Debt a problem?

In a word, no. Debt drives growth. It is one of the greatest human inventions which makes it possible to manage resources in time. We must, however, realize that every clever shortcut we take now is a piece of technical debt, and will become due tomorrow. We make things easier today by moving the hurdles to the future.

The real problem is not debt itself. It is debt management, and more precisely bad debt management. As we all know, unmanaged or badly managed debt leads to a catastrophe with mathematic precision. It is thus quite strange that, despite all the clever people gathered in IT, underestimating the technical debt is the norm across many software development companies, IT projects and IT business in general.

Some people believe that technical debt is related to the product quality. In reality, it is related to the reusability of the IT product, not its quality. The more debt gets attached to an IT product, the more difficult it is to modify or reuse it in the future. Moreover, technical debt management is also related to the organization maturity. Following solid strategies, mature methodologies and basing the daily actions on facts instead of wishful perceptions, means that you prepare well for the future and you have a plan to repay the technical debt in full.

Technical debt accompanies the “IT product”, not the “development project”. It is attached to the product throughout its lifecycle, and remains there long after the development project is over.

Speed of Delivery vs. Technical Debt

Speed of delivery is important in a competitive IT market. Fast deliveries make everybody happy. But concentrating too much on the delivery date tends to make people take ugly shortcuts and ignore fixing them after the delivery date.

The development project closes successfully and people congratulate each other, but the product remains with an attached debt.

When we take shortcuts we must remember that nobody can really gain time (or gain anything). There is a price for everything; you push something on one side and it comes out from the other. If somebody says “we are gaining time” think that this is not possible. Nobody can gain time; you can only manage time (that is borrow time from the future and use it today). So, whenever you hear somebody saying “we are gaining time”, consider it equivalent to “we are addiding technical debt” and ask for a debt payment plan.