A definition of technical debt and how to monitor it
Software developers tend to be under a lot of pressure: customers want new features and managers want to release these features as soon as possible. This urgency is understandable, but it also has a downside: it often forces engineers to introduce technical debt.
Technical debt is created when a solution to a technical problem is chosen that works in the short-term but will cause more work down the line. Release pressure is a common cause for accruing technical debt. It fixes a problem in the here and now, but a ‘debt’ is created that will have to be paid back eventually. And just like with debt, the longer you wait with paying, the more interest accumulates, and the more difficult it becomes to pay back.
Technical debt can creep into a software product trought several ways. The first one is unintentional technical debt: a junior developer writes code in a way that is very hard to read, maintain, etc., and for some reason this goes unnoticed and ends up in the product. Ways to ensure this does not happen are having thorough code reviews, using pair programming or having good code checkers in place.
But technical debt can also be intentional: a manager must decide how Feature X will be implemented, and there’s a lot of pressure to release soon due to certain circumstances at an important customer. The manager can decide to do it the ‘quick and dirty’ way to ensure the deadline is met, and schedule some time in the next release to properly implement the feature in a clean way.
Sadly enough, in practice, the next release will also have a tight deadline and no time to properly work away the technical debt accrued during the previous release. You can guess what that means: technical debt keeps piling up, with the interest you need to pay back increasing as well.
The consequence of all this technical debt building up within your software is that over time, it becomes harder and harder to make changes. The development organization grinds to a halt because too much short-term thinking has led to an unworkable code base. Implementing even the simplest of features takes a long time. This is usually the moment management notices that end-users are getting dissatisfied with how slow deliveries are.
Technical debt is not always bad: sometimes the long-term must be sacrificed to satisfy an important customer or to win a certain project. However, it is important to be aware of the debt you are building up, and not forget that you will have to pay it back sometime.
So how can you measure where technical debt is building up within your system? You can use our software quality framework TiCS to determine which parts of your code base are becoming hard to maintain. If you’re interested in seeing how much technical debt you have, request a free proof-of-concept.
Request a free proof-of-concept