Do you know the term technical debt? Wikipedia describes it as “a concept in software development that reflects the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer.” (https://en.wikipedia.org/wiki/Technical_debt) This is certainly a correct definition, but there’s more to it. We’ll get to that shortly.

Yesterday I wrote

Anyway, it’s important to take care of quality right from the start of the project. Don’t fall for the idea of redoing it later. Refactorings are common, useful and will happen, but don’t plan for them from the beginning.

My good friend Tino brought to my attention, that I did not mention an important fact: (paraphrased by me)

Good planing also accounts for planned technical debt, instead of accumulating technical debt during the project because of factors like the cost of the project, fear of delays and bad decisions.

Thanks, Tino!

So why should you plan for technical debt (TD from here on)? A low TD approach is commonly perceived as superior. But, accumulating TD might be beneficial under certain circumstances. This could be that you plan for a very short release to attract early adopters or because you want to be first-to-market in a heavily contended market, or with a new feature. Another point why TD might make sense in your project is the following: TD always has a certain risk associated with it. The risk could be increased costs in maintenance of this part of the application. Now imagine that you create a part of your app, where customers can get in contact with you and receive first-aid in using the software—like a help-desk. You know that, at some point in the future, you will outsource this whole part of the app to a third party who will take complete, good care of your users. Now you can transfer the whole risk of this part and the TD associated with it, to an outside player. They are experts in this thing and won’t use your help-desk module but their own software. So you don’t have to worry about it while creating it, and you don’t have to worry about maintaining it in the future.

This, again, makes it clear why a good plan is crucial for the success of your project and for the quality of your work.

Yours, Holger