The concept of technical debt gets a lot of air time from architecture gurus like Ward Cunningham, Martin Fowler and Neal Ford. The cost incurred by sacrificing design for other project constraints such as time to market does indeed resemble financial debt in many ways. Like paying interest for an item bought on credit, the complexity created by shortcuts taken now impose an additional cost every time we are forced to work around them in the future. Unless we go back and “pay down” that technical debt, we get to enjoy that interest payment for the life of the project.
Technical debt isn’t necessarily viewed in the most positive light. Still, I think the world has been looking at it through rose colored glasses. The picture is always painted as though the architect or developer taking on the debt were making a conscious decision. As though they carefully weighed their options and came to the conclusion that the prudent decision was to take on some technical debt in order to capitalize on a business opportunity. If that were the case the cost of technical debt would be much easier to swallow because its existence would at least have been recognized and justified by someone. Let’s get real here; a lot of the people holding these debts are software development’s version of a college kid that thinks a credit card is free money. They’re not salty software veterans making calculated choices based on risks and rewards. They’re eager neophytes haphazardly throwing applications together using one hack after another.
This is the breed of technical debt that I truly despise. It may not be technical debt in the sense that someone knowingly took a shortcut based on some external force but ignorance doesn’t change the fact it is technical debt just the same. Perhaps those who coined the term would disagree with that, but it sure feels like I’m paying the same “interest” when I’m forced to deal with the resulting bad design.
Along with making future changes more difficult (interest) and the cost of refactoring to eliminate poor design (paying down the principle) that comes with all technical debt, this type of technical debt comes with a special hidden expense. Since it seems to be fashionable to talk about intangible project costs in terms of financial metaphors, I like to call this the Anger Tax. This is the time you spend being angry when you encounter this type of technical debt in the future. When design is compromised based on some sort of tactical business decision it’s a little more forgivable. When you’re called on to help establish a bailout strategy for a project that is failing under the weight of shameless, unmanaged technical debt you tend to look at the debtor like they're the president of AIG. Paying down their technical debt is angry work and that anger isn’t free. Every roll-your-own hack and framework misuse that irritates you is an interruption that negatively impacts productivity. These distractions make it difficult to stay pragmatic about refactoring as you are easily drawn into idealist thought tangents about how things could have been if only you were there before things went awry.
With all of that ranting out of the way, I must admit that I don’t really have any great answers for avoiding technical debt created via programmer negligence - I just like to complain about it. Perhaps requiring some sort of board exam or apprenticeship for architects would help but that's probably not very realistic. I probably shouldn’t be so angry about it anyway since a solution would be financially crushing for me; resuscitating poorly designed applications is a large part of what keeps guys like me working. While I may not have a cure, I do find ranting, sharing war stories and commiserating tends to lighten my mood on the subject - hence this post. I’m always up for hearing a good anger tax story so if you have one, feel free to vent here.
Posts
Great article, Chad! Again, this can crop up in the Design and UI world as well. My biggest grievance is that regardless of who incurs the technical debt, it's usually some other schlub who pays the anger tax.
ReplyDeleteGreat points Chad!
ReplyDeleteOf course there are two other major causes for this : management and project growth.
Quite frequently we can be forced into situations where we have to create this despite protestations and attempts to explain the issues that will crop up later due to this, yet are still held accountable for the "tax" that comes up during maintenence and expansion.
The other is project growth which happens easily when you've designed solutions that meet the problems you know about as well as the ones that were likely to arise. Then you get a laundry list of new requirements that would've been near impossible to predict and have to shoehorn them into the product. In that respect I suppose this would end up tying into the first one, as most good architects should then raise protest for the same reasons.