Hacker News Reader

Comment by Ottolay | Hacker News Reader

The difference though is that financial debt is very easy to measure and quantify but technical debt is not.

I like the Tetris analogy because that game has a type of debt that anyone who has played it can understand, yet is not as easily quantifiable as financial debt.

View on HN

I guess the analogy still works because not all debt is monetary.

You might owe a debt to the mob. Perhaps they help you out of a sticky situation but let you know that some unspecified favor will be required in the future. So you have a debt, but what exactly you owe is loosely-defined and might cause great chaos in your life at some inconvenient point when it's time to repay.

While I fully agree that financial debt is easier to measure, and some forms of it are very easy to measure, I don't think it is always very easy to measure. Perhaps it may be a difference in what counts as debt, but I see many people engaging in decisions that require future payments without considering those payments at all, much less viewing them as debt. For example, getting a pet dog can have numerous costs associated with it but people don't always consider these as debt. And the average person (fully based on my own personal anecdotes) isn't going to be willing to give up the dog just because it is costing them money. So while there isn't a legal due that you can be taken to court for, I still think it counts as a form of debt.

Your talking about assets and liabilities. All debt is a liability but most liabilities are not debt. Owning a dog is a liability, not a debt.

Then should we talk about technical liability and compare it to financial liability? Maybe that would be a closer comparison than using debt in both cases.

I personally like "deferred maintenance". Similarly doesn't have a monetary value to it, unless you actually do a check-up where you could calculate it (man hour estimations).

It's like financial debt, but we can can't tell you what the interest rate is.

That's a good point. I think of any given project as a CDO. There are good, productive debts and bad, stinking, potentially crushing debts in there. What matters is not that there is debt - I think there will always be - but what the blend is.

If the debts were thoughtful and deliberate with understood risks, they might make perfect sense.

If the debts were taken by people who couldn't evaluate them and had no business making that decision, it's going to be bad.

Odds are the first are well-understood and maybe even documented. The second may explode when the underlying assumptions or risk changes.

Ref: https://www.investopedia.com/terms/c/cdo.asp

or if you'll ever have to pay it back. Just because you have some tech debt doesn't mean you'll actually have to ever deal with it.

I was going to say the opposite, just because you'll "pay it off later" doesn't mean you're not paying for it now, with every single change taking longer than necessary.

why not both?

Sounds like debt to me. With all the refinancing going on I wouldn't be surprised if there's still some debt out there that can be traced back to someone centuries ago that hasn't been payed back yet.

It's more like a compound interest. A financial example would be payday loans with an incredible APR and a low monthly payment, your debt is forever increasing.

Or the unit of measure. It's really hard to tell what sort of technical debt you are taking on and building for contingencies that may never manifest is it's own type of sunk cost. That's (a) why projects need to have some strategies that move forward without excluding lateral (or minor-backtracking) moves, and (b) why software development is inherently hard.

And I might add: what is technical debt in one project, maybe isn't in another project.

Engineers sometimes want to overengineer things that would work just fine in that situation. I remember an old link about someone studying the source code of a game (Doom maybe) expecting to find beautiful solutions for every minor problem when in fact he was surprised by how most of it was straightforward.

Check what needs to scale/be resilient before reinforcing the code there (and of course, if the solution is already frail at the moment it probably needs to be fixed sooner rather than later)

I live my coding life by this philosophy: The best code is the stuff that looks like any novice could have written it, but only an expert knows how hard that is to do.

(bonus: write your code like the next person to work on it is a psychopath and they know where you live)

> financial debt is very easy to measure and quantify but technical debt is not

For business school grad PMs I like to see if they can run with an analogy to selling unhedged call options rather than thinking of it in terms of debt with a known payoff schedule.

Even the bankers got derivatives wrong at an epic scale.

I wonder if there was a time in history where financial debt was not well understood. This would have to be either before the invention of algebra, or possibly also during a time of very poor education.

> or possibly also during a time of very poor education.

So, you mean today? The number of students that take on crippling amounts of student loans without truly understanding how it will affect them is staggering to me. The ease of obtaining credit before a person truly understands how devastating 20%+ interest rates are is also pretty telling. Financial debt is easy to get wrong, and is only compounded by the fact we don't teach this as a basic course in primary schools.

Even worse, many think they understand finances without realizing there is a difference in corporate versus personal financing. The rules don't necessarily transfer between them.

Or just large numbers. A valid strategy to invest a million will be worthless with just a dime. No matter what the silly myths of success say.

Reply on news.ycombinator.com