Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Technical Debt Is Like a Tetris Game

fluentcpp.com

Post reply on HN
Print view View original

61–70 of 122 posts

Re: Technical Debt Is Like a Tetris Game

#61

Post by humanrebar »

jwr wrote: post #56
humanrebar wrote: post #50

Earlier quoted context omitted.

If it never costs you anything, it's just a design decision, not technical debt. Plenty of projects never upgraded C versions, so old C is maybe not technical debt. But plenty of projects are upgrading python versions now, so old python is often technical debt.

No, there is an important difference. It's technical debt because you might have to pay it back, but it might also turn out that you will be switching directions altogether and in that case the debt gets forgiven.

All code might need to be tweaked though. Even talking about stable C, the toolchain under it might become unsupported, requiring a port. That means every system include and compiler definition is technical debt.

Re: Technical Debt Is Like a Tetris Game

#62

Post by jahewson »

SkyBelow wrote: post #41
Ottolay wrote: post #32

Earlier quoted context omitted.

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.

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 asso…

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.

Re: Technical Debt Is Like a Tetris Game

#63

Post by adrianmonk »

Ottolay wrote: post #32
newbkoder wrote: post #29

The best analogy for technical debt is debt - that is where it got the name from! Just like financial debt, technical debt is not necessary a bad thing, but a tool - and something to manage, control and track. And just like financial debt, taking out too much technical debt without paying it back can crush you. There is nothing wrong with taking out a mortgage (and thus getting into debt) to buy a house - you just ne…

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.

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.

Re: Technical Debt Is Like a Tetris Game

#64

Post by _ea1k »

smitty1e wrote: post #17
heisenbit wrote: post #11

Earlier quoted context omitted.

Like with Tetris sometimes you find a block that allows for retirement of a lot of old stuff. But maybe this block never comes. Or maybe it comes only after you papered over the debt and the solution does not work anymore.

Then there is the false sense of security coming from a skilled player deftly obviating tech debt. Until that player departs, and the team is buried.

That's an interesting analogy and it has two sides. A skilled player might hide a lot of technical debt without even realizing it.

An unskilled one might see a lot of it that doesn't even exist.

Re: Technical Debt Is Like a Tetris Game

#66

Post by wnevets »

Angostura wrote: post #43
Ottolay wrote: post #32

Earlier quoted context omitted.

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.

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

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.

Re: Technical Debt Is Like a Tetris Game

#67

Post by thetedhogan »

humanrebar wrote: post #61
jwr wrote: post #56

Earlier quoted context omitted.

No, there is an important difference. It's technical debt because you might have to pay it back, but it might also turn out that you will be switching directions altogether and in that case the debt gets forgiven.

All code might need to be tweaked though. Even talking about stable C, the toolchain under it might become unsupported, requiring a port. That means every system include and compiler definition is technical debt.

There's a difference between a toolchain becoming unsupported, and putting a hack around a feature that later becomes obsolete due to business decisions. That hack could certainly be technical debt, up until it isn't. If the code that it was implemented in is no longer used in the future, you didn't incur any cost to it.

Not an original idea but I can't remember where I heard the idea. Technical debt is the best kind of debt, because it's the only debt that you might not have to pay back.

Re: Technical Debt Is Like a Tetris Game

#68

Post by aeturnum »

newbkoder wrote: post #29

The best analogy for technical debt is debt - that is where it got the name from! Just like financial debt, technical debt is not necessary a bad thing, but a tool - and something to manage, control and track. And just like financial debt, taking out too much technical debt without paying it back can crush you. There is nothing wrong with taking out a mortgage (and thus getting into debt) to buy a house - you just ne…

A monetary metaphor for technical debt implies a freedom to the order of addressing technical debt that is deceptive. This comes from money's fungible nature: if you have many debts, you can pay off whichever debt you want and you can pay it off in parts.

I think this metaphor does a good job of capturing the path-dependant nature of debt. How the size of each individual debt sits in the shadow of the code that relies on the flawed code. Understanding that there's the work of fixing technical debt and the work of getting to the place where you can fix technical debt feels more clearly communicated by tetris than by financial debt.

Re: Technical Debt Is Like a Tetris Game

#69

Post by mbesto »

Ottolay wrote: post #32
newbkoder wrote: post #29

The best analogy for technical debt is debt - that is where it got the name from! Just like financial debt, technical debt is not necessary a bad thing, but a tool - and something to manage, control and track. And just like financial debt, taking out too much technical debt without paying it back can crush you. There is nothing wrong with taking out a mortgage (and thus getting into debt) to buy a house - you just ne…

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.

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).

Re: Technical Debt Is Like a Tetris Game

#70

Post by humanrebar »

thetedhogan wrote: post #67
humanrebar wrote: post #61

Earlier quoted context omitted.

All code might need to be tweaked though. Even talking about stable C, the toolchain under it might become unsupported, requiring a port. That means every system include and compiler definition is technical debt.

There's a difference between a toolchain becoming unsupported, and putting a hack around a feature that later becomes obsolete due to business decisions. That hack could certainly be technical debt, up until it isn't. If the code that it was implemented in is no longer used in the future, you didn't incur any cost to it. Not an original idea but I can't remember where I heard the idea. Technical debt is the best kind…

It doesn't have to be a hack to be technical debt. Anything with a shelf life, even out of date design, has risk and costs. The old python 2 is technical debt even if it wasn't a hack. Something needs to be done, it's just a question of what and when.
Post reply on HN