This is a fairly common sort of technical debt, and again one that can be laid at the door of developers.
In financial terms this can be thought of as borrowing too much money and then paying high interest payments. In technical terms this is seen in the over-engineering of systems to build a level of complexity that is just not needed for the system being built.
This results in longer development time, larger amounts of bugs and much more complex ongoing maintenance. The analogy for this is building a hatchback and putting a Formula 1 engine in it (just in case one day it needs to enter a Grand Prix), and then giving it a lifetime warranty.
It was this sort of technical debt that the agile concept of YAGNI (You Aren’t Gonna Need It) was introduced to address. If it is not something that you need right now, then don’t build it. As we discussed in Positive Technical Debt part 2: Structured Finance, YAGNI can also lead to the development of technical debt, but that technical debt is positive and can be controlled.
This type of technical debt is the most negative form as it is very difficult to control. By its very nature it is something that often only becomes apparent when it is already is existence (if it was spotted in advance, it just wouldn’t be done).
Following agile practices, focused development, regular architectural reviews and experienced developers are all ways of dealing with this problem.
In the final post of this series I’ll talk about how to manage Technical Debt (subscribe). In the meantime, why not take a look at the whole Technical Debt series, where we discuss many forms of positive and negative technical debt?