I will describe my understanding of "technical debt". It may well be different than your understanding of technical debt, but I think if you look at it this way you will be able to answer the question.
The idea behind a company acquiring debt is to increase the number of possible options now at the expense of increased constraints later. So, for example, you borrow $X today which means that you have the option to buy things that would have been impossible without the loan. Later you must repay the loan which means that you will be able to buy less things.
The hope is that you will be able to leverage the extra money to put yourself into a more advantageous position in the future. Having done so, you can handle the constraint of paying back the debt much more easily. For example, let's say that you borrow $100. You buy a lawnmower with the $100 and use it to mow lawns for $10 an hour. After 2 weeks (80 hours), you have made $800 mowing lawns which would have been impossible without the loan. Paying back the $100 is easy because you have $800 to play with.
As a side note, in early stages of a company growth is often constrained by capital, so it is considered irresponsible not to borrow money by many analysts. You should borrow as much as you can get, up to the level of the constraint because that will maximize your growth.
Enter "technical debt". When doing development, there are often many choices to make. Some choices will result in opportunities now at the cost of constraints later on. For example, imagine that you have a meeting with a VC company. You need a demo that shows the vision of your software. You know that you can not build anything functional in the amount of time you have, so you simply write a throw away demo. None of the code can be used in the final product, but it is good enough to show what you mean and it can win the VC money.
In this case, we have the future constraint that we must completely rewrite all of the demo code after the VC meeting. But we were able to raise capital, and continue building the company due to our efforts.
That's a pretty extreme example, but another example might be something like this. We could do a usability study for your new UI to make sure that it works well for the user right from the beginning. Or we could just code up the simplest UI that we can think of. The second choice will cost less and allow use to get it into the hands of the user early. Possibly this is important because we need to beat our competitor to market with a feature. We will still have to do the usability study at some point, and refactor all of our code, but hopefully we will be in a better position to afford that extra work later on.
Just like real debt, there can be problems. For example, imagine that we borrow $100 and instead of buying a lawnmower, we buy beer and drink it. We've had a good time drinking the beer, but now we owe $100, have no way to pay it back and have a hangover to boot.
The technical equivalent happens far more often to companies than the money thing (although, I often wonder what happened to all those Aeron chairs that the dotcom companies bought up in the late 90s). You often get a naive CEO who thinks, "We should take on as much debt as people will give us because we can leverage it to build growth!". So they say, "Don't worry about the future, just give me code as fast as you possibly can". He isn't sitting there thinking, "I am taking on future constraints, but can I actually use this to leverage my growth?".
You get in a situation where the coders are just hacking their fingers off, but to no actual benefit. You end up with no way of mitigating the bad code (repaying the debt) and you have the headache of dealing with all the grumpy programmers who leave to find a company where they can "do it right".
You asked, "Where is the evidence that technical debt, let alone organizational debt, is actually related to the economic indicators of success?" The answer is that it is not necessarily related. It depends on what you have done with that debt. If you have simply had an orgy of coding madness without leveraging the opportunities to increase growth (as many startups do), then there will be no relation.
My own personal view of this is: programmers should be in charge of the "technical debt bank". They should do their best not to incur debt, but if they are asked to do so they should ask a question of their own, "How are we going to spend this debt?" It is important that the programmers understand the business issues so that they can "loan" an appropriate amount of debt. If the business is basically saying, "Keep giving me debt. I don't care how much. And we're going to spend it on beer and Aeron chairs", then the responsible programmer/banker should perhaps have a serious chat with the business.
If you are with a good organization, though, the answer will usually be of the form, "We need to get features X,Y,Z done by this date so that we can bring in W revenue. Once we have accomplished that we will be in a better place to repay the debt".
Thanks for that. Yes, there are definitely some circumstances where thinking in terms of risk is a plus.
As a bit of a dovetail, I had another random thought after typing the previous message. Technical debt is a little bit different than monetary debt because if I borrow money to leverage the business, the business (hopefully) grows in the same currency that I borrowed. I make more money and can pay it back.
Technical debt is different because even if I make a lot of money by taking a technical short cut, it doesn't mean I will have the capability of repaying the "loan". The people who made that short cut may not be capable of refactoring the code. Hiring people who can do the work seems like it would help, but then you have all the problems discussed in the original article.
Looking at it from the risk perspective, it can be a lot clearer that you might want to avoid the situation right from the off. Although the person who prompted me to write my response has unfortunately been entirely unhelpful, I suspect that's what they were ultimately thinking. "Will you actually be able to pay off this technical debt even if you grow the business?" Sometimes you can look at your staff and say that the risk of failure is nearly 100% ;-)
We can theorize all day. Where is the data? The truth is we don't know how to guarantee business success, except via shotgun techniques (funding lots of random attempts). This strongly suggests that technical debt is not that important of a construct.
How is your position distinct from, "I don't understand X, ergo X can't be very important"? Because it looks pretty much the same to me.
If you think each business is a "random attempt", I hope you're never a founder. Modern businesses are highly non-random. It's true that investing in startups is in some sense gambling, but it's gambling on a highly filtered subset of all existing businesses, which is in turn a tiny fraction of all possible businesses.
The "where is the data" line is especially misleading here because no data just means no data. There are no high-n, double-blind studies validating the concept of technical debt. But there are also no studies demonstrating it's not a useful concept. And that's most of life: the decisions we have to make rarely can be solved by looking up journal studies. When that's the case, we have to apply other tools.
Again, I see this as you mistaking "I don't understand" for "there is nothing there". I obviously don't think it's handwaving, and it has been a long time since I took unsupported accusations from Internet randoms very seriously.
Sure, you could be a very special snowflake, so smart that the world really does always break down into "obvious to brobdignagian" and "dumb/meaningless". But if you're that smart then I'd suggest that either a) you should use your smarts to make your Olympian view comprehensible to us mortals, or b) you're wasting your time talking with the likes of us.
Technical debt isn't just a startup thing. It's ever-present in tech organizations. Technical debt is probably a leading factor in the irrelevance and ultimate death (typically sale / merger) of most software companies. The product gets increasingly buggy over time as developers pile on more and more hacks to get features out the door without writing down the debt, and customers move on to competitors that have fewer bugs. This is what happened to Netscape, for example.
For startups, technical debt can show up as unreliability (remember Twitter's fail whale?), or it can sink a product before it ever becomes famous enough for you personally to remember.
The idea behind a company acquiring debt is to increase the number of possible options now at the expense of increased constraints later. So, for example, you borrow $X today which means that you have the option to buy things that would have been impossible without the loan. Later you must repay the loan which means that you will be able to buy less things.
The hope is that you will be able to leverage the extra money to put yourself into a more advantageous position in the future. Having done so, you can handle the constraint of paying back the debt much more easily. For example, let's say that you borrow $100. You buy a lawnmower with the $100 and use it to mow lawns for $10 an hour. After 2 weeks (80 hours), you have made $800 mowing lawns which would have been impossible without the loan. Paying back the $100 is easy because you have $800 to play with.
As a side note, in early stages of a company growth is often constrained by capital, so it is considered irresponsible not to borrow money by many analysts. You should borrow as much as you can get, up to the level of the constraint because that will maximize your growth.
Enter "technical debt". When doing development, there are often many choices to make. Some choices will result in opportunities now at the cost of constraints later on. For example, imagine that you have a meeting with a VC company. You need a demo that shows the vision of your software. You know that you can not build anything functional in the amount of time you have, so you simply write a throw away demo. None of the code can be used in the final product, but it is good enough to show what you mean and it can win the VC money.
In this case, we have the future constraint that we must completely rewrite all of the demo code after the VC meeting. But we were able to raise capital, and continue building the company due to our efforts.
That's a pretty extreme example, but another example might be something like this. We could do a usability study for your new UI to make sure that it works well for the user right from the beginning. Or we could just code up the simplest UI that we can think of. The second choice will cost less and allow use to get it into the hands of the user early. Possibly this is important because we need to beat our competitor to market with a feature. We will still have to do the usability study at some point, and refactor all of our code, but hopefully we will be in a better position to afford that extra work later on.
Just like real debt, there can be problems. For example, imagine that we borrow $100 and instead of buying a lawnmower, we buy beer and drink it. We've had a good time drinking the beer, but now we owe $100, have no way to pay it back and have a hangover to boot.
The technical equivalent happens far more often to companies than the money thing (although, I often wonder what happened to all those Aeron chairs that the dotcom companies bought up in the late 90s). You often get a naive CEO who thinks, "We should take on as much debt as people will give us because we can leverage it to build growth!". So they say, "Don't worry about the future, just give me code as fast as you possibly can". He isn't sitting there thinking, "I am taking on future constraints, but can I actually use this to leverage my growth?".
You get in a situation where the coders are just hacking their fingers off, but to no actual benefit. You end up with no way of mitigating the bad code (repaying the debt) and you have the headache of dealing with all the grumpy programmers who leave to find a company where they can "do it right".
You asked, "Where is the evidence that technical debt, let alone organizational debt, is actually related to the economic indicators of success?" The answer is that it is not necessarily related. It depends on what you have done with that debt. If you have simply had an orgy of coding madness without leveraging the opportunities to increase growth (as many startups do), then there will be no relation.
My own personal view of this is: programmers should be in charge of the "technical debt bank". They should do their best not to incur debt, but if they are asked to do so they should ask a question of their own, "How are we going to spend this debt?" It is important that the programmers understand the business issues so that they can "loan" an appropriate amount of debt. If the business is basically saying, "Keep giving me debt. I don't care how much. And we're going to spend it on beer and Aeron chairs", then the responsible programmer/banker should perhaps have a serious chat with the business.
If you are with a good organization, though, the answer will usually be of the form, "We need to get features X,Y,Z done by this date so that we can bring in W revenue. Once we have accomplished that we will be in a better place to repay the debt".