One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to.

When you're validating an idea, don't worry about making everything perfect. Worry about validating the idea. Once you're more confident that you're actually gonna do it long-term, then it starts being more beneficial to pay off the tech debt.

I think what you're saying is the more common use of "tech debt", basically just using it as a synonym for "bad code". Don't worry about code quality, figure it out later.

It ignores the stronger debt analogy -- sure, there is a high chance that the idea fails. But if it succeeds and, all else being equal, you have taken on a less tech debt to get there, you will be able to iterate on and grow it more efficiently. So to the extent you're taking on debt, it should be an explicit trade-off to increase your chances of proving out the idea. Which is not the same as "don't worry about bad code at all."

From what I've seen, when it comes to talking about tech debt from an early prototype, it's often an excuse/euphamism to be considerate to the people that wrote it. The truth is often that it's just bad code due to them being inexperienced or lacking the skill or discipline to write better code. Which I don't mean as an insult, it seems like there's a strong inverse correlation between the kind of person who's passionate enough about product over tech, and is creative/naive enough to build and validate a brand new product, and the kind of person who understands enough to architect a great system and make the best tech debt trade-offs.

I absolutely agree - that's the whole point of the article and my comment. If you're in an experimental space, and 9/10 of your ideas are never going to make it to market, I'd rather spend 1 units of time on each to figure out which one's going to work, and then 20 units of time redesigning it the right way (i.e. 21 units of time to be done), rather than 10 units of time on each to make them all ready for production (i.e. 100 units of time to be done). But those ratios will vary depending on how sure you are about what needs to be done next, so yes - you've gotta weigh the cost / benefit.

> One important difference between tech debt and financial debt, is that if the project you accrued a bunch of tech debt in gets killed for unrelated reasons before it's completed, your debt is forgiven. You never pay it off, and you never have to.

This happens with financial debt as well. It's the risk that drives interest rates. Financial debt is abandoned (or restructured) when people or companies file for bankruptcy, when homes are foreclosed on, etc. Sure, it might ding your personal credit history in some cases, but financial debt is constantly abandoned at little or no cost to the borrower.

I thought interest rates were more driven by inflation. Mortgages are insured, for instance, removing much of the risk, but you pay for that insurance much of the time (THAT'S driven by risk), but $500,000 is worth more now than it will be in 30 years, so you're gonna have to pay to get it fronted to you.

Maybe a better word than "technical debt" is "rusty Ferrari".

Would you accept a free rusty Ferrari tomorrow? If it would take $60k in repairs to get into usable form, and probably not that great even if you put in those repairs, which you have no inclination to do, probably not. Especially if you couldn't easily sell it. If you were a broke college student and it was in roadworthy condition, and you had no other way to make it to your job - probably you would.

This captures that it's not really that you're "$60k in the hole" if you accept the free rusty Ferrari. In a sense, yes, you are.

I propose rusty Ferrari as the new, more precise term for technical debt. "We have a lot of rusty Ferraris in our garage" isn't a debt, but I think might capture the meaning. "I don't want a rusty Ferrari in my garage" = I don't want this technical debt. Let's make it work with some rusty Ferraris = let's cobble together a hack we should probably throw away.

what do you guys think?

There is no difference. Regular debt is also discharged in bankruptcy.

But that affects your ability to borrow in future, whereas a canceled project doesn't affect your ability to write rushed code in future. Unless you get fired, I guess...

You’re nit-picking when I think the analogy is clear but it doesn’t effect your credit if the company you work for declares bankruptcy, so the comparison to the company’s tech debt seems to hold up even if you push it.

The whole thread is nit-picking. The point of bankruptcy isn't "fuck being fiscally conservative - we don't even know we want the stuff we're buying so who cares if we can pay our credit card bills", whereas that's literally how you should approach some projects.

Commercial lending has this component as well. Any real estate operator working at scale will have some experience with giving this or that project back to the bank.

Isn't that more of a similarity than a difference? When financial debt gets overwhelming you can declare bankruptcy and abandon the project as well.

No. Bankruptcy doesn't just eliminate the debt and let you move on consequence-free - it's a legal process in which a plan is put in place for everyone to get their fair share of what's left, or to recover from the debt without the debt itself destroying future productivity. It can also be very detrimental to your credit opportunities. If you abandon a project, you're just never going to repay the debt or suffer from any consequences of it.

delete the whole code (or just throw away the keys) and all the debt is paid.

> I think mostly where it goes awry in the wild is people forgetting the paying it off part.

Which also fits the financial debt analogy perfectly.

What would bankruptcy be analogous to... the business going under? Having to rewrite the application due to unmaintainable code?

Probably a rewrite – HNers always seem to have stories about being brought in to work on companies with incomprehensible rats nests of code that are impossible to extend any further. I bet that's pretty common, more common than technical debt actually forcing the company under.

Still if you really want to take the analogy further declaring technical bankruptcy could cause business bankruptcy (see Joel Spolsky). You probably want to refinance your debt and get onto a repayment plan (an incremental rewrite) instead.

The key part analogy isn't bankruptcy so much as interest. You incur technical debt and you pay it off later in interest (by spending time to clean up the hacky code). If you don't pay off the interest, you end up incurring even more technical debt. Eventually, you could end up paying several times more in interest than the principal (end up spending more time working around the hacky code than if you've just addressed the issue properly in the first place).

Bankruptcy is more correctly letting you get away from obligations to creditors with lesser terms to the creditors than originally agreed because you can no longer pay it back. I think there’s nothing very close to this for technical debt because even in a rewrite there’s new debt involved. A rewrite is a lot closer to refinancing where the value of the asset is re-evaluated and new terms of debt repayment are structured that stakeholders agree to. Most people seem familiar with chapter 7 bankruptcies but there’s 11 and 13 too. Furthermore, bankruptcy is about handling an original amount lended - rewrites oftentimes are done with lessons learned from the original version (rewriting from Python to Go isn’t bankruptcy).

Technical debt bankruptcy is probably closer to shutting down a service / product with no replacement - the effort has already been spent and you’re walking away from costs without caring for the creditors (customers and engineers alike).

The question of whether technical debt can be zeroed in a technical bankruptcy is who the creditors of technical debt really are - is it the business as a whole or the engineers that maintain this stuff?

To me, the state of technical debt bankruptcy is a business in a zombie state unable to grow to service the debts because of the technical debts keeping them uncompetitive rather than something more fundamentally wrong with the business like product market fit or bad reputation.

Virtualization probably comes closest for a subset of scenarios.

Bankruptcy occurs when your debt exceeds your ability to it off. I suppose that would be the point at which it's easier and cheaper to write new code than try to fix the old code. The debt can no longer be paid back. That said, somehow there are still COBOL programs running, so even though that program should shut its doors and liquidate any useful assets, real world money prevents that from happening.

oh it definitely is a rewrite

Ward Cunningham, who coined the term "Technical Debt", would often use the analogy "If you borrowed $500K for a house that is now worth $1M..."

Michael Feathers said that he doesn’t use the term when working for banks as they don’t see it as a negative term...

A big part of technical debt is that often... you just don't have to pay. This is what makes the comparison to financial debt a very poor one.

Whenever I'm moving from one framework to another I find loads of todos I can now delete. Or even if I have a well designed class, if I can find a nice third party library that does the exact same thing, I can now get rid of all that useless code and any debt around it.

Honestly I think calling it technical 'debt' makes programmers unreasonably averse to it, but unfortunately I haven't been able to come up with a better term.

So you're declaring tech bankruptcy.

Tech debt is mainly a problem with code that needs frequent updates as it makes changes harder.

If you have messy code that doesn't need updating, then it doesn't cost a thing to leave it in a bad state. The act of refactoring in these cases is a waste of effort and often does more harm than good by introducing bugs.

I take the YAGNI when it comes to refactoring. Just pay back the stuff if the code actually slows you down in the future instead of doing it in advance.

There is a lot of tech debt you can get away with for free without ever having to pay back.

> The article links tech debt to financial debt early on, and this is exactly what the analogy is - it is best to be as literal as possible about it.

Financial debt has a clear quantitative measure.

Tech Debt is an incredibly fuzzy concept, even as a qualitative measure, to the point of being useless for anything other than covering one's ass. We can do better as engineers than resting on such fuzzy thinking.

I'm curious what you think is better. Any links you could share? I suspect you're wrong, or not quite right, tho. Technical debt is a great analogy and even if it's fuzzy, being able to think about the relevant tradeoffs in a familiar way is too useful to ignore.

Surely there are situations in which it's only useful to cover one's ass, but often it's a great way of explicitly understanding specific tradeoffs being made.

At any given crossroads in a business endeavor, you encounter a problem.

Now you have two choices:

1) You select and articulate your assumptions. You select and articulate your requirements. You also may try to capture and articulate your Black Swan list of unknowns and risks. The key thing is that you are clear. Clear what you know and clear about your concerns and risks. You then articulate your solution, holding it accountable to your assumptions, requirements. And then you move forward.

- or -

2) You come up with some solution sketch. You have a general vague notion that it isn't ideal. You're not sure why but it just doesn't feel right. You need a way to psychologically contend with this vagueness. So you give the vagueness a name. The first thought that comes to your head is: "Vague Notion That This Design is Not Very Good". This is not very flattering to your ego. So you think a little bit more and come up with: "Tech Debt". And you like this, because it sounds quite nice. It sounds like you're back in control, that you know what you're doing. You proceed to blame the design deficiencies over time to "Tech Debt". Everyone nods their heads.

I work on a product with a large amount of tech debt, and that debt was almost universally created using the methodology in your first category. Most of it is extremely well documented. That doesn't magically make it not technical debt.

Debt implies you consciously accepted it.

What you’re describing with your product is the fruit of unskilled (amateur) labor.

Yes, it's a nebulous metaphor. Taking it too seriously is a mistake. But I'm not sure we can do much better? What would you suggest?

I like the Go concept of aji [1] but that's too obscure, nobody will get it. Maybe something like "unfinished business" would work? A nebulous term for a nebulous concept.

[1] https://senseis.xmp.net/?Aji

What I suggest is you try to run a project and deliberately avoid reaching for the concept of "Technical Debt".

You will find yourself squirming a little. It will be uncomfortable at first. But if you hold to your guns, you will find that you're forced to speak in much more clear terms about your process and decision-making.

And you will certainly find yourself saying humble things like "I have a sense that this isn't the best solution, but it's all I got right now."

But over time you'll find yourself improving. You'll find yourself saying "I have a sense that this isn't the best solution -- oh, you know what I just realized, this design choice is going make this other requirement over here nearly impossible to implement."

And with this kind of clarity you'll be in a much much better position to navigate the territory ahead and make clear, conscious decisions based on what you know and don't know.

"Tech Debt" is simply a way to dodge -- e.g., dodge the discomfort of not knowing stuff, of holding yourself to clear thinking, of admitting the need to improve...

A little trickier maybe in that some tech debt is in the eye of the beholder. Some may consider an Angular UI tech debt, others might consider it an asset versus, say, React + whatever other parts it needs.