Technical Debt in Agile Software Development
by Kelly Waters
Martin Fower - agile software development guru, and CTO of Thoughtworks - has written an interesting blog post about Technical Debt.
I love this concept. It's so simple, and such a compelling way of explaining this classic commercial trade-off decision to business people.
Kelly.
I love this concept. It's so simple, and such a compelling way of explaining this classic commercial trade-off decision to business people.
Kelly.
27 February 2009 16:01
Martin's article is balanced and well written.
Personally I feel too much is made of "technical debt". In my experience most systems which have huge "technical investment" are worse than those with focussed effort.
The truth is that you typically don't (and arguably shouldn't) know "the answer" when you build a software system, you just know the problem and how to measure whether your answer worked. It generally takes a few attempts to get the answer and the architecture right (one of the best engineers I have worked with suggests 3 attempts as a rule).
The beauty of agile approaches is they recognise the value of refactoring, and have the automated, test-driven discipline to make this low risk.
Build it quickly (80/20 smart) - check it does what is needed and has real value - then refactor if it really is as important as you thought (99% of the time it won't be).
So to use the modern economic model.
Worry about the good debt.
Ditch the rest into "toxic assets" and switch it off as early as you can. If it ain't "doing the right thing" there is no point in worrying if "it is doing the thing right".