Backend team: As we are building an MVP, this database table will have a poorly designed schema we will iterate on later.

Frontend team: We need some data that only exists in that other team's database. We will accumulate some technical debt by reading their database directly. This will let us deliver working software quickly.

Backend team: The time has come to refactor that badly designed schema.

Frontend team: That will break everything. You must not do it.

Backend team: Please will you pay off that technical debt?

Frontend team: It's not hurting us much at all, and we would rather be working on new features and things that make money. We are busy and many people are asking us for important things. Here is a link to an article saying technical debt is not a bad thing.

Backend team: I am sad because I'm stuck looking after this badly designed table. I wish I had done a big design up front.

Technical debt should be viewed the same as any debt. With a major caveat being that there is no time limit on it. And to that end, you don't always have to pay down your debt.

The problem, I think, is everyone applies personal financing to thinking of technical debt. Very rarely can an individual accrue debt that will allow them to make money. It is not at all uncommon to make a design trade off that "pays dividends" pretty much immediately.

And, not too shockingly, xkcd has a good visualization on this. http://xkcd.com/1205/ (Granted, I can see how this is not necessarily the same thing. But I often feel that what folks call "technical debt" is really, "I wanted a jet liner solution for what a walk down the street could have accomplished.")

I think it relates the discussion of why software is an especially hard thing to write.

A simple way to put it is, "planning a large system is harder than you think it, for any value of 'you'". With another large part being that no only is calculating the time spent on the project hard, calculating how long or short the project will be is hard. And "harder than you think" means that no matter how sophisticated one gets, bad estimates will tend to seduce you based on the deadly combination of ignorance and wishful thinking - everyone experiences wishful thinking and everyone is ignorant of the real implications of a large enough new system.

Now, technical debt involves getting some momentary gain in the present based on planning to take of the problem in the future. And by that token, technical debt will expose you to the risks of planning a larger system immediately.

And this isn't to argue that one can or should eliminate technical debt - just that there's every reason to be more wary of it than ordinary debt.

My personal take, is the debt is actually taken out against the knowledge of others. That is, in technology, knowledge is the currency. To take on technical debt, then, is to leverage other peoples knowledge.

This sounds dangerously close to my saying technical debt is the opposite of NIH. And to an extent, I think I am. Pretty much, identify the areas where you/your company will take full ownership of the technology versus the areas where you will rely on the solutions of others.

I think the metaphor can be seen as double edged in this regard. Companies such as Google can afford to make massive investments in custom build workflows/etc. Smaller companies can not afford these investments and instead must work with standard "off the shelf" ones.

That is, your company may not be able to afford avoiding some technical debt. And the vast majority of the "debt" you take out will never need to be paid back.

Many metaphors can be partial metaphors and still be useful.

I agree with your point that the ordinary debt that enterprise takes hinges on asymmetric knowledge - I think contemporary economics sometimes looks at it that way.

Consider there are different kinds of debt. Gambling addicts will frequently barrow money to gamble more. They get a certain high from gambling and they have a delusional idea of their odds of winning. I think the worse sort of software technical debt can equate to this - the planners merely have a delusion that they have a better idea of the risks and rewards involved than other people.

I agree that most companies have to take on technical debt. I think they do pay for it in the form of miserable programming environments, bad software and canceled projects. It is true that once a project is canceled, the technical debt is gone and unpaid. But most of the world's bad debt isn't actually paid - unless the Mafia decides you should sleep with da fishes...

Consider, many folks that are writing PHP level apps do not know how the full HTTP stack works. Expand that, most people writing web apps of any flavor have a small understanding of this.

For most of us, this is not a big deal and never becomes due. We took on some technical debt by trusting the frameworks that we have chosen to handle them for us.

However, if any of us find ourselves at the scale of Facebook, Twitter, etc, then we find that suddenly a lot of the tiny details of HTTP start to matter. To the point that solutions that minimize resources and the like suddenly matter. Heavily.

All too often, however, people use this argument in favor of "shiney new framework." Taking on struts was technical debt because you offloaded much of your core to them. I question whether many companies truly needed to ditch fully working struts implementations in favor of "new shiney," though.

And then, this metaphor can be extended in amusing ways. There was the assertion that git took on unnecessary "technical debt" by remaining in C instead of C++. Instead, it can also be seen more as they took on the cost of not having abstractions unto themselves.

So, my assertion is that for most projects, the benefit of a technical debt never outweighs the downside. Not because the project will "go away" but because it just is never really a problem.

Your gambling example is amusing to me. Few people will ever consider that healthy debt. It is one thing to have a sponsor, and another to have an addiction.

My experience is in medium-sized-institutions rather than giant soft-centric firm like Facebook or Google or the single-web-app startup. I think this is where the majority of programmers still work.

Here, projects "always" last longer than you think and effects of shortcuts accumulate in an unfortunate fashion.

You can say technical here is a "good choice" when it happens to be an unavoidable choice. But when it is an avoidable choice, I see it as "always" a bad choice.

-- And my quoted "always", I mean "often and more often than it is your naive impulse to think so that it's better to say always than to just guesstimate that it might not happen in this case 'cause you'll be swayed by wishful thinking"

That is, debt should be considered in this regard the same as a loan for money. Taking out a loan to get something done quickly and with little effort has a huge benefit. So does picking a framework that you can hire a lot of folks for.

Further, and this can be subtle, if you are going to do this, then you bloody use the money/technology according to the terms of the entity lending. How many people hate maven because they decided that its way just wasn't good and wanted to tweak it? How many people, on immediately taking up a new technology, look for how they want to do it first? Before they have even understood how that technology was made to be used?

This is not to say there may not be reasons to leave or tweak a technology. But, realize for most companies it is not a viable proposition to do so. Instead, accept and leverage the disadvantages and limitations of the technological "debts" you have taken out.

A lot of terrible UI code may be acceptable as it rarely infects the rest of the system where a smaller design bug in a tiny utility library may end up causing worlds of pain even if it's rather elegant code that could be reused on other projects just fine.

You are taking out a debt against their knowledge in getting your application off the ground. This directly so if it has to be licensed, but equally true for free frameworks.

My argument is that for many people this will never be a problem. Consider how many games farm out the heavy graphics coding to libraries.

For many software companies and content producers, the content that you are producing is the value they bring. Trying to morph the actual value of a company into a new way of doing this is risky.

Which brings me to a comment I made in another subthread. The one thing people need to remember is that when you take out technical debt by using a framework or library, you are basically entering a contract to do things their way. Take great care when you break this contract.

Our whole financial, investment, and saving system is based on this statement thankfully not being true. You can't successfully save money or value of any kind unless someone successfully borrows it (I.e. Uses it productively).

The rest of us? We take out loans to buy houses and cars. Usually of much higher value than we needed. Or, even worse, to buy toys and other household items.

Seriously, when was the last time you took out a loan on something that had a financial return?

Cars are often necessary for transportation. I don't have one, but if I was living in the states they could help me save time and get to work (where I make money). Of course, there is a point where buying a used car with cash makes sense, but there is also a point where buying a car new under a loan makes sense (depends on loan costs, interest, car price, etc...).

Taking a loan out for college can make sense, considering the returns you make afterwards and the lower interest rates often offered through government programs.

I personally haven't bothered with a loan yet (consumer or otherwise, no house or car, but living in China is a bit different from living in the states), but I can see the utility of it.

Consider, there are cars that are perfectly serviceable used or for less than 15k. Yet many people are aiming for cars from 20 to 50k. Then there is housing. Look how well treating housing as an investment worked out last go around.

College is an interesting one. I always cringe when I hear of folks taking out 100-200+k loans for college. That just blows my mind, and has led to both a sense of entitlement for higher wages and general wage inflation.

Though, my economic acumen has reached its end in this post. I do not know enough to really speak whether these loans are terrible ideas.

Interestingly, I think this actually makes it somewhat applicable to the technological debt as I framed it. If the majority of your value add is in leveraged technology, then you will have a hard time of it. Where these lines are between good and bad debt, I do not know.

Maybe not make money, but certainly spend less money. Energy efficiency upgrades immediately come to mind. Eating well is another.

Similarly, if you had upgraded to CFLs when they were in their infancy, you would have terrible lights that have a long power cycle and provide little light. (Though, today I get annoyed with family that refuses to buy better lights.)

Most amusingly to me lately, I saw a "call for papers" about converting to DC in the house. Our AC power is effectively "technical debt" in the house hold. Moving from that to a more efficient DC source to power all of your DC items in the house would make sense. Using DC back in the day would not have.

Eating well is an odd one, I think. Rarely are people taking out loans to get food. You can certainly spend your capital more wisely on food, but I'm not sure it fits the metaphor.