Technical Debt is a metaphor coined by Ward Cunningham. It refers to anything that isn’t done right during development. This includes things like breaking coding rules, introducing potential defects, increasing code complexity, code duplication or even ignoring necessary documentation. We’ve all been through crunch time and when something needs to work and work right NOW, the ends begin to justify the means.
There are quite a few sources describing technical debt, why it is bad, ways around it. There are even applications that try to calculate the actual cost of your technical debt.
It is funny all the ways developers need to “trick” management into appreciating elements of our craft. I cannot remember the last time I spoke to a developer about the monetary cost of using something as fundamental as SOAP vs REST. Yet, here we are, trying to make developers care about the actual value to the company of things with the hope that developers caring about budget and cost will somehow get management caring about the code.
I mean, sometimes technical debt makes sense. Startups are rarely known for their innovative programming improvements and more for their innovative programming. That isn’t to say startups can’t produce elegant code that is a pleasure to work on and easy to enhance. Some probably do, but those that try, likely don’t last long. When you are a startup, money is tight. A few dollars of incurred technical debt today are easily covered by the billions you will be worth in the future...
At least you get to wear a hat afterwards.
The real problem with technical debt, even for startups, is that most developers are perfectionists. A study done (link) found that…
87.3% of respondents believe that delivering high quality is more important than delivering on time and on budget.
Not only is that number high, but it was the highest factor when compared with scope, time, staff and money. For me, this says that not only is technical debt bad for the code environment, but it is just as bad to the programmer’s environment and morale.
That is exactly why SCRUM sometimes includes a refactoring backlog to be worked on after releases, as much for improving the code as improving team morale. There are few things more rewarding than slaying dragons. Code dragons that is.
If you want to read more about technical debt, read this article. It really does the best job I have seen analyzing technical debt from both developer/management perspectives, as well as, what is really important about technical debt.
UPDATE: It appears someone else was thinking about technical debt.
Available here.
0 comments:
Post a Comment