A Mess is not a Technical Debt
blog.objectmentor.com
blog.objectmentor.com
A mess is definitely a technical debt. It's going to take time and money to clean it up. You can put it off more, but it's going to make everything cost more money and take more time than it should. Or you can clean it up now and save that time and money.
Debt is one way that companies get ahead when they are first starting out. Just like borrowing money, you can borrow time from the future as well. Instead of making an immaculate product, you make something that gets the job done and fix or rewrite it later.
And just like money debt, if you don't pay off your technical debt, it will be a real pain. And the longer you wait, the more expensive it is.
Seriously, the analogy is crazy good.
Perhaps another distinction Uncle Bob could have made is between hidden technical debt (i.e. the mess that PHBs refuse to acknowledge) and acknowledged technical debt. Uncle Bob is talking about the latter, where everyone agrees some trade-offs were made up-front.
The former is much harder to wrangle because, so often, the decision makers are unwilling to accept that it even exists ("well, the system's working fine, isn't it!?")
The interest payments are analogous to friction that you ought to be feeling day to day when you're carrying around technical debt. New features are more expensive to build, more bugs are popping up in these areas that are slowing the team's progress, etc.
People like to think they didn't make a decision like: "I know this code is shit, but I'm going to push it live anyhow." But they DO. Every time. They just lie to themselves about it being shit.
I'm even going to argue that there IS a time and place for shitty code. Startups are a great example of this. Get some barely working code up and going (incur debt) and then fix or rewrite it (pay the debt off). This gets the business earning money and moving forward as quickly as possible, and there's time later (if you don't put off the debt too long) to clean things up.
The problem is that it doesn't have a $ amount attached to it, so many business types can't see it. They just see a working system and can't imagine why you want to spend more time and money on it. (Not that I really blame them... They can't see it.)
Mess is like adjustable rate mortgage.
You might be able to pay down the former, but you may go underwater if the latter goes way above what you imagined in your worst case scenarios.
Of course, all of this is far afield of the point. I thought technical debt was a fairly simple concept--you borrow from the future for some present benefit; you do something today that you have to pay back tomorrow. Once you chase down the metaphor this far, it's no longer a useful metaphor. Your technical debt will not be subject to quantitative easing.
http://www.youtube.com/watch?v=pqeJFYwnkjE&t=4m18s
He explains that technical debt is code written before you have a complete understanding of the problem to solve. You repay the debt by refactoring it when you have a better understanding. This only works if the code is clean enough to be refactored.
I once paid off a technical debt incurred by a previous programmer who had done a code and dash of epic proportions. The code was utterly horrendous, and so many changes had been done in-place, right on the production server, with hard coded paths, that we had to rewrite it bit by bit. We didn't even know all the functionality in it, other than that it was in active use (we found and interviewed people to get a full sense of what it did). It took years, but we did pay it off.
Technical debt also means making a mess. Because you were trying to get it out the door asap. Or you didn't really understand the paradigms of the language you were using. Or the framework. Or because that part of the system was written by someone who's not a very good programmer. Or because requirements changes and you didn't have time to fix it properly as the db schema change was too massive to do all at once. Or one of the many other reasons.
Because so many people use it that way, that's the definition now.
tbh I have no idea what Uncle Bob's talking about in that blog post, it didn't make much sense to me and he really seemed to be grasping at straws with that example.
You use a crappy old paradigm (frames) because you're not good enough at the new one (ajax) as no-one really knows what to do or what works best and there are no established patterns to copy yet. Why you then need more tests or more pairing when the code's simpler and the paradigm's known to everyone doesn't ring true to me at all.
These days of course the opposite is probably true of that example.
Maybe.
> It's going to take time and money to clean it up. You can put it off more, but it's going to make everything cost more money and take more time than it should. Or you can clean it up now and save that time and money.
Nope. Lots of code is abandoned for external reasons. All effort spent on it was wasted, including "clean it up now".
A mortage or a credit card balance is debt - you must deal with it. Crappy code is different - it is often abandoned without any consequence.
let's coin a term, "muju". What the author describes as technical debt is good muju, and a "mess" is bad muju.
I believe in the same good muju / bad muju concepts. The only difference is that I use the term "technical debt" to refer to both of them. While the author only uses technical debt as a non-pejorative term, I use it as both a pejorative and non-pejorative term.
For me, the analogy of debt still works -- its all a matter of how responsible you spend the money. Take a home equity loan as an example. Spending it on renovating the bathroom and kitchen is (at least historically) likely to be a positive ROI. That's good muju (the author would say "technical debt", I would say "good technical debt"). Spending it on a new sports car would be bad muju (the author would say "a mess", I would say "bad technical debt").
In money, debt is debt, whether you acquired it by taking out a responsible mortgage or running up your credit card on bottles of Dom Perignon to impress your friends. In software, technical debt is technical debt whether it was wise or not. The point is, you're paying for it when you try to do other work on the project (interest) and it's gonna take time to fix (principle).
Saying "A mess is not technical debt" is silly. The metaphor is useful whether it was a good idea to get into debt or not.
Edit: s/Don/Dom/ -- thanks for the pointer!
I think I'll just go back to the plain words. There is good code, bad code, and ugly code. There is flexible code, and brittle code. There are planned short-term jury-rigs, unplanned baked-in design mistakes, and fragile temporary solutions that never get fixed because the company pivots before it matters.
The business world has a fairly well developed set of nuances around whether the debt a company has is good debt or bad debt. AIUI Ward's original point was simply that the "all debt is bad" approach doesn't work in business, and shouldn't be applied in so blunt a manner to technology either. Sometimes it's worth going into some debt now to achieve a future benefit. But, a business should be just as careful with its technical debt as its financial debt: only going taking it on with a clear (and well measured) path out again.
But, as you say, like pretty much any metaphor, stretch it too far, and it falls apart.
With that in mind, I've never seen a codebase with any technical debt.
Uncle Bob is simply trying to draw a operational distinction between technical debt that is accrued deliberately and technical debt that is accrued out of sloppiness.
That later is a transgression that is definitely a mistake and should be avoided, the former is a calculated risk that is a part of this business. It doesn't matter what you call them as long as you recognize the difference between these two conditions and what they mean.
I mean yes, presumably since I haven't saved enough for retirement yet, I have "retirement debt". As long as you live, you always have some kind of debt because you could use your future time to earn more money (or create cleaner code or whatever). So I suppose you owe yourself your future self.
It is debt in the widest sense - but not a useful concept. Obviously you have to do in the future what you can't do today.
Technical debt is merely a chimera created by consultants who want to justify their high costs.
Another illustration: if I build a tent to spend the night, have I accrued technical debt because I owe myself a proper house? shakes head
To use your tent illustration, there's no debt because you don't plan to grow the tent into a proper house - the product is finished.
Now, if you actually wanted to build a two story house, but built a tent instead for now because summer's already here, you'll then have to "pay the debt" of dismounting the tent so you can rebuild the house properly.
Another danger with the technical debt thing is that it could lead to expensive premature optimization. For example while you are camping out in your tent, maybe you get a job offer in another city. Or a motorway is about to be built across your lawn. Had you needlessly started with heavy foundations of your house, that effort had been wasted.
Who benefits from the TD theory is the builders of the house foundations. Or the consultants who want you to use Java Enterprise Beans instead of Sinatra.
If it causes inefficiencies that could have been avoided, it's technical debt, regardless of the cause.
For example, a system was built crappily, and you refer to it later on as incurred technical debt. bzzt wrong, if you didn't call it technical debt when the system was being built, it probably was just a mess and now you're calling it technical debt to hide the crappiness.
But, a crappy mess will become a technical debt the moment you recognize it and make a business decision not to spend time on fixing it right now.
No, actually it's the exact opposite, both in the short term, and in the long term.
Short-term vs. existing homeowners: http://www.nahb.org/generic.aspx?sectionID=734&genericCo...
Long-term vs. non home-owners: http://www.philadelphiafed.org/research-and-data/publication...
More: http://econ.jhu.edu/people/ccarroll/papers/COS-WealthEffects...
There is a lot more info out there about this, but the economics of it are pretty simple. The fact that the author can't even get this right makes me question any other assertations made in the article.
1. There is a difference between a bad decision and a trade-off that you will (probably) have to re-visit in the future.
2. Writing messy code is a bad decision.
Irregardless of whether you think point two has merit, point one is the the soul of the article.