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.
> 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.
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.
Why can't you repay the debt by just rewriting the code instead of refactoring it?
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.
It may not be what he intended but that how's the term is in usage.
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.
I think you actually agree with him. Perhaps an analogy will help. "Technical debt" is like when you go to the bank and get a loan. There are terms for paying it off, and while it is debt that you should probably avoid, you have a plan for paying it back. "A mess" is like when you just stop paying your bills. You're getting yourself into debt, but you made no arrangement to get yourself out.
No, we're definitely disagreeing. Because a mess -can- be cleaned up, and it can be chosen consciously. In fact, it always is.
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.)
You can still go underwater on a fixed rate mortgage, can't you? Underwater is when you owe more principal than the house is worth. Houses can lose value.
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.
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!?")
Again, the analogy is crazy good. You're just ignoring the interest payments. If you're actually not feeling any pain then it's quite likely that you haven't taken on what I'd call technical debt (or that you've taken on some sort of deferred debt, similar to 0%-interest-for-1-year style furniture purchases).
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.
A mess very definitely is technical debt. True, as opposed to the "clean" debt that Uncle Bob's advocating, it's a bit like getting expensive cash advances on a credit card or going to a loan shark. A mess is likely to be a lot harder to discharge than the technical debt that comes from careful well-crafted decisions; the approaches you need to take may be different; and there's an increased chance that you won't be able to get out from the burden of debt. But it seems to me that all of those points fit in very nicely with the general analogy of debt, and I'm not sure why Uncle Bob thinks otherwise.
I agree conceptually, though I happen to map different semantics onto the same concepts.
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").
I'm throwing up my hands and giving up on this metaphor. It was a nice try, but from what I can see, the heat-to-light ratio is way out of whack. Every discussion of "technical debt" either gets bogged down in definitional issues ("is there a difference between debt and a mess?", "Is it debt if it was planned but not if it kind of happened by accident?") or it gets bogged down in overextension as people try to figure out the metaphorical equivalent of "interest" or "refinancing" or "bankruptcy". As if any of these concepts necessarily applied.
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.
I think the metaphor is mostly lost on people who have never taken a business loan. Generally banks don't like lending money to companies purely to cover normal operational expenses. If you simply have cash-flow issues then a line of credit/overdraft is better. If you can't meet your costs out of income, then you want to either reduce costs or find an additional equity injection, not take a loan. Traditionally loans are for things that will grow the business, with a clear path to being able to repay it out of the additional income generated as a result. Obvious examples are buying expensive new equipment to let you produce something you sell at a greatly reduced cost, or opening new retail outlets.
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.
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.
Totally tangentially to the post I just confirmed that it is called Dom Perignon and in doing so I learned that they have a massive technical debt with their website. Or maybe the requirements were in the line of, build us the slowest flash website imaginable and can you create a loading graphic that looks like a rendering issue?
I like this distinction. I think a lot of people hear about technical debt and then feel OK about writing shitty code. But in reality, taking on technical debt is a calculated engineering risk, not sloppy work that "a mess" is.
With that in mind, I've never seen a codebase with any technical debt.
I think some people are getting retentive about applying the "debt" metaphor.
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.
Or you could just launch. This technical debt thing has to be the silliest meme ever.
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
I'm far from an expert, but from what I can tell the debt occurs because you'll have to "pay" it to move on.
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.
Sure, but I think you could almost always make the case that whatever you do, you have incurred "technical debt". Otherwise you would make perfect decisions all the time, which is impossible.
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.
You may choose not to call it technical debt, but you have to call it something, and it seems very much a debt to me. The term you use to describe it doesn't get to cast judgement as to the merits of the debt. The debt may be inherited debt from an acquisition, for example. Any judgement you would choose to cast regarding the debt's merits does not necessarily reflect on the current holder of that debt, but the debt is just as real. If I buy your company and you have debt on your books from stupid decisions that did nothing to advance your company, it's still debt that I now owe.
If it causes inefficiencies that could have been avoided, it's technical debt, regardless of the cause.
Here's another way to look at it. Technical debt is real when you see it first when looking forward, before it's realized. Technical debt is bogus when you see it first when looking backwards, after it's 'realized.' Like real debt, it doesn't just 'appear' without a conscious decision to incur it.
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.
The way I define technical debt is something that risks wasting someone's time. If you decide to make a change quickly to get something working and create a mess in the process, then it's possible that that mess will waste someone's time when it comes to making other changes. Note this is separate from a mess that can cause bugs. For example a significant lack of unit tests I would classify as a business or data risk - anything that risks losing customers should be given higher priority than technical debt.
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.
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.