Technical debt

Technical debt is a way of describing some of the costs you can incur when building software. For example, when implementing a feature in a system you generally have two options.

1. Implement the feature quickly, knowing that it will make future changes to the system harder.
2. Implement the feature with more care (using time/effort) resulting in a better design and more robust implementation. This makes subsequent changes to the system easier.

There is a clear trade off here. You can liken technical debt to financial debt.

When incurring technical debt, as with financial debt, you will have to pay "interest". In the example above, the interest you pay on quickly implementing the feature is the additional cost required to implement subsequent features. You can continue to pay the interest each time you add a feature or you can repay the principal by going back and implementing the original feature properly.

Note that technical debt, like financial debt, is sometimes useful. In the same way that you likely couldn't buy a house without going into debt, sometimes you might struggle to deliver an application or system without taking on some technical debt first. Examples of useful technical debt are as follows...

• Quickly building features so that users or business sponsors can see functionality.
• Quickly building features to attract more customers or satisfy existing ones.
• Quickly building features (or a whole product!) so that you get first mover advantage over competitors.

In most circumstances the driver for taking on technical debt is time, for example, you have to deliver the software on a certain date.

However, like with financial debt, you must take care not to go bankrupt. Should the interest payments exceed your capacity to repay them, you are finished.

Should you be spending all your effort on simply paying down the interest on your debts, you will be unable to move your project or business forward. At this point your your project or business will fail.

There are many examples of technical debt. Not having an automated deployment mechanism is common. Not having such a thing saves you the time it takes to implement one. The trade off being that this costs you time/effort for each occasion you deploy your application, because you have to do the deployment manually. You can either invest the time to implement an automated deployment and then experience very low cost for subsequent deployments or continue with a fixed cost for each release. Note that if the application has a short lifespan, and you will only deploy the application a few times, then it's simply not worth investing in the automated deployment mechanism. Continuing the financial debt parallel, this is similar to renting a car versus buying a car. The automated deployment is like buying the car - large up front cost giving a low cost for subsequent uses. Where as manual deployments are like renting a car - zero up front costs but a fixed cost for each use.

Like most things in software, its a matter of weighing up the costs and benefits. Taking on technical debt can be justified but should be clearly acknowledged if it is. In the vast majority of times there should be a plan to pay off the debt.