DevOps Zone is brought to you in partnership with:

Dror Helper is an experienced software developer has written and designed software in various fields including video streaming, eCommerce, performance optimization and unit testing tools. He is passionate about programming best practices and all things software development, and has been a guest presenter at several user group meetings and ALT.NET events. Dror's blog can be found at where he writes about unit testing, agile methodologies, development tools, programming languages and anything else he finds interesting. Dror is a DZone MVB and is not an employee of DZone and has posted 57 posts at DZone. You can read more from them at their website. View Full User Profile

Is it ok to have technical debt?

  • submit to reddit

Technical debt and design debt are synonymous, neologistic metaphors referring to the eventual consequences of slapdash software architecture and hasty software development. Code debt refers to technical debt within a codebase.

[From Wikipedia]

If you’re doing something that you know that will return to bite you in the ass someday than you’re probably in the “technical debt” department. It can be anything it might mean that no unit tests were written for a feature or that no upfront design was made before coding – depending on the team and project. In fact technical debt is all around us - from missing stages in the CI (Continuous integration) process to quick and dirty coding and missing features.

Avoiding technical debt is close to impossible - unless you are a true craftsman, have a patient and understanding boss (and no deadlines) you might be creating debt as you go along.

debt - by Alan CleaverBut it’s not all bad – because unlike actual debt you might not have to pay interest - some of the time it might actually go away, requirements change or additional code is written and from time to time problem just go away. You might find out that something that was nearly impossible yesterday become easy today just because you’ve learned something new.

I’ve learnt to treat technical debt just like any other known risk  - it should be treated and managed - ask yourself what the worse that could happen – will I pay more on a less favorable time (e.c. deadline) and how much time would it take - and decide if it’s worth not doing it right now.

Having said that – there is a catch, it’s way too easy to use technical debt as an excuse. From time to time I get to hear a fellow developer say something such as: “I won’t be doing X because it would take too long and we’re already behind schedule”. The problem with that statement is that I usually have the feeling that he did not think about the consequences of not doing what might be done – because sometime it’s easier not think about tomorrow. The solution is simple – just ask him: “what would happen if you don’t do it” – and then listen – because he might convince you that creating debt at this place and time is ok.

From time to time you might even convince him that he should do what he’s avoiding right now – and by doing so you’ll make your team better.


Happy coding

Published at DZone with permission of Dror Helper, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


George Kalfopoulos replied on Thu, 2011/11/03 - 12:15pm

I recently wrote myself about technical debt in if anyone wants to read more about various types of technical debt...

An interesting subcase on when technical debt might not be too bad is when you do not have to pay it yourself. A number of large european organizations/institutions split large software projects into separate procurements. So it is entirely possible for your company to do the design and analysis, another one to do the construction and yet a third one to get the helpdesk and maintenance. This also depends on what type of company you are employed (

So in such a scenario, technical debt by the first company will have to be resolved by the second one or occasionally as you say that debt might removed by questioning some of the analysis, or as the construction progresses some features become obsolete and unnecessary (so any incomplete analysis, gaps in the documents etc. that would constitute technical debt are also obsolete). In a similar way technical debt from the second company might pass on to the third one.

There is of course the job ethics point of view (as in how ethical is it to pass on your problems to the next guy?) but I will leave that aside.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.