Hacker News Reader

Comment by wccrawford | Hacker News Reader

Totally disagree.

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.

View on HN

> A mess is definitely a technical debt.

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.

Ward Cunningham disagrees with your interpretation of his metaphor.

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.

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.

One of the "refactorings" in Fowler is "change algorithm", which I think is a bit of a cheat.

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 know your language has failed you when you can't even agree on whether you're agreeing or disagreeing.

Technical debt is like fixed rate mortgage.

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.

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.

I mostly agree with you.

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.

"well, the system's working fine, isn't it!?" is analogous to "I haven't hit the limit on my credit card yet".

Even worse, there isn't a hard limit on technical debt. You can't plan for it. When you do hit the limit, you're up against the wall.

Reply on news.ycombinator.com