Friday, 27 February 2009

Technical debt

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.


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:

Thursday, 12 February 2009

View from my new office - sunset

View from my new office - sunset, originally uploaded by garyt70.

January has been extraordinarily busy, February is working out to be the same.

Decided to make at least one post that stays in place after several failed attempts to do a blog entry with JavaScript and DHTML.

This Photo is from the office window in the building Altio has moved to, nice views all around.