What a great term “technical debt”.
I picked the term up from Martin Fowlers blog entry call “Technical Debt”. You also need to watch the video talk by Ward Cunningham to understand the background to the metaphor.
Debt
When developing software you can accrue two types of debt, financial and technical. Both can result in the failure of a project or organisation.
Financial debt is common to everyone – you have to pay salaries, rent and for computers etc. If you are lucky this is paid for through income, otherwise by borrowing.
Technical debt according to Cunningham is not about poor code but writing the best code given your understanding at the time. You can rush software out of the door, but you incur debts which may need to be paid back. I say “may” because if the software is not successful or is meant to be thrown away as an experiment, who cares if you cut corners. Unless of course the reason for failure is because you cut corners.
Don’t accumulate financial debt for the sake of reducing technical debt unless you are very confident of success.
Technical debt can be as crippling to the roadmap of a product as financial debt. I feel the difficulty for someone managing software projects is balancing both debts and negotiating with stakeholders and development teams to get debt balance right.
Don’t pass the debt on
My personal choice is to write the best interface to the outside world in the hope that end users not impacted by later changes. If you don’t put enough effort into achieving high quality external interfaces then you are passing your debt on to others, especially if changes need to occur later.
This may mean that the internal features not expected to be used by others must accrue your technical debt. The technical debt has to be paid back through refactoring later.
Don’t hide the debt
As the financial credit crunch has shown hiding bad debts in clever delivery mechanisms can only lead to disaster, especially when it gets to the point when nobody understands what is going on, or does not want to understand because things are great at that moment in time. If the project is accruing debt make contingency plans, and make it clear to stakeholders why the contingency plan is required and the risk the project is exposed to.
The bottom line
Don’t try to achieve perfection first time, unless you have lots of money to spend. Get the balance between a perfect system that you can be proud of and a system that delivers business benefit with the least financial and technical debt.
Financial debt is short term, technical debt is long term but can be addressed after first succeeding, once the money is flowing you won’t incur further financial debt.
Finally, it is better to deliver a working project than to never complete a perfect project.
Forgot to add this reference: http://blogs.construx.com/blogs/stevemcc/archive/2007/11/01/technical-debt-2.aspx
2 comments:
A good example of a large technical debt that wasn't paid off until the very latest they could get away with it has to be Twitter.
Joel Spolsky and Jeff Atwood brought up exactly this in the last stack overflow podcast
I guess Twitter are still accruing the financial debt.
These are good points but you have to be careful with technical debt. Ever felt like you're paying it off before a project is finished? Ever feel like there's a debt you never paid off?
Tom,
Good commnents.
You and I are working on projects now where we are paying a high price for technical debt.
..never paid off? No my credit cards are clean :-), still paying for the mortgage on my house though. Technical debts - yes, because the finacial cost outweighed the benefit of clearing the technical debt.
Post a Comment