Technical debt as formulated by Ward Cunningham is a term to describe the obligation that a software organization or development firm incurs when it chooses a design approach or development method that serves its purpose in the short term but increases complexity and is more costly in the long run.
Often this is used to achieve faster deadlines for delivering a software project at a lower cost, but just like financial debt, some tech debt can serve valuable business purposes but at the same time may be counterproductive.
There are two basic types of technical debt:
- Unintended technical debt
This technical debt is a non-strategic consequence of poor business performance.
Example: A developer delivers a program that works at first, but at a later point it turns out that the design approach is prone to error or a junior team member wrote a bad program.
In another example, this type of debt could be incurred also without knowing. The company you collaborate with may have a significant technology debt that it’s only discovered after the acquisition of the software product.
This debt can also be created when a team falters in its efforts to rewrite an indebted platform and inadvertently creates more debt.
- The intended technical debt
This usually happens when a company makes a conscious decision to improve the present rather than the future.
“If we don’t complete this release on time, there will be no next release” is a common phrase – and often compelling. This leads to decisions like, “We don’t have time to juggle these two databases, so we’ll write some glue code (a quick fix) that keeps them in sync now and find a better solution after handover.” Or “We have some code written by a contractor that does not follow our coding standards; We’ll clean it up later. ‘ Or “We did not have time to write all the Unit Tests for what we developed in the last two months, we will implement these tests after go live”.
How do you deal with technical debt?
Avoid accumulating small debts
That debt builds up from taking hundreds or thousands of little abbreviations – generic variable names, scattered comments, creating one code class in a situation where you have to create two classes, not follow coding agreements, etc. This type of debt is similar to credit card debt. It’s easy to unintentionally tolerate, it adds up faster than you think, and it’s hard to track and manage after you’ve incurred it.
As an entrepreneur, you need to take into account the technical debt when choosing the team that will develop your business.
Some offers from beginner programmers may seem to you a lot less than others, but in the end, you can save yourself a large debt in the future if you choose a professional team at the beginning.
Handle and track debts in your program
An important implication of tech debt is that it must be serviced, meaning that once the debt is incurred, there will be interest charges.
If the debt grows enough, the company will ultimately spend more on servicing its debt than it will invest in increasing the value of its other assets. A common example is the old code base in which a lot of effort is put into keeping the production system running (i.e. “debt service”) so that there is very little time left to add new capabilities to the system.
You can maintain a list of debts within the Defect Tracking System.
Every time a debt is incurred, the tasks necessary to pay off that debt are entered into the system along with an estimated effort and schedule.
The accumulated debts are then tracked, and any debts that have not been resolved for more than 90 days, for example, are treated as critical.
Of course, in the end, technical debt is analogous to financial debt. Firms have different philosophies about the utility of debt. Some companies want to avoid taking on any debt at all, while others see debt as a useful tool and just want to know how to use it wisely.
Devista – Your way into the future!
