I’ve been reading a lot about technical debt recently where people alternate between voluntary technical debt or inadvertant debt. Without doubt, every project has some level of debt, but the important thing is how much do you have, and when do you plan on paying it off.
Martin Fowler says
“Technical Debt should be reserved for cases when people have made a considered decision to adopt a design strategy that isn’t sustainable in the longer term, but yields a short term benefit, such as making a release. The point is that the debt yields value sooner, but needs to be paid off as soon as possible.”
Technical debt is an excellent way for an architect or developer to communicate the cost that a particular decision or implementation made in the short term will affect the project in the longer term.
While in words this works fine, I wonder if there is some type of formula that we can apply to illustrate and track the debt of a project. For each item in the project that causes some debt, it needs to have interest (the cost of not addressing it) and principle (the cost of refactoring the issue to make it work).
While principle could be the number of man days to fix it, I’m stuck with how to express the interest. And how do you work out how much technical debt a project can actually afford. I’m interested to hear if any of you have used the technical debt metaphor in your projects effectively?
There are different types of technical debt, which Martin Fowler describes very neatly in his quadrant diagram:
Reckless and Deliberate
The cost of racing making the deadline at all costs. Once it runs it’s ok right?
Reckless and Inadvertant
Creating a mess without noticing that they’ve done so. Without bringing in any design patterns or real knowledge/experience, debt it going to happen, without the team realising how much of a mess they’ve created.
Prudent but Inadvertant
“If I was starting again, I’d do it differently”. While things were done to the best of the teams ability, we find that there will be a better way.
Prudent and Deliberate
Voluntary debt. The team knows that it’s not quite right, but it’s better to ship and accept the technical debt that will arise because of this.