Live data from Hacker News

Technical Debt Is Like a Tetris Game

fluentcpp.com

81–90 of 122 posts

Re: Technical Debt Is Like a Tetris Game

#81
People talk about technical debt like it accumulates to a point where you can't go on, but as someone who has worked at a company with totally overwhelming, malignant tech debt, teams can and do go on, for some definition of "going on." Don't get me wrong, it is an absolute miserable place to be. It's like a software purgatory, where things "work" but also mysteriously don't work sometimes. Will you be punished for implementing new feature X? Nobody knows--that's for the tech debt monster to decide.

I believe that learning how to identify a team that is drowning in tech debt is a valuable interview skill.

Re: Technical Debt Is Like a Tetris Game

#83

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…

Financial debt is fungible and liquid, but the tetris analogous shows how technical debt is neither.

Re: Technical Debt Is Like a Tetris Game

#84

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…

And just like real debt, you can just walk away from it at any time with no obligation right, not even on your credit rating? Just look at the debt and say "don't want you no more" and the debt says "aw shucks. Guess you don't feel the benefit of paying me. I can understand. So all right. I won't complain.", and the debt goes and disappears, down some dark alley with a bottle of scotch, no debt collectors ever hound…

Sure, defaulting does decrease your credit rating, as your example of 50 $ change for 150000 $ more in debt illustrates. And yes, there is a point further borrowing will be rejected, as sibling comments in this thread mention.

So, excluding the actual strawman numbers, analogy still holds very well.

Re: Technical Debt Is Like a Tetris Game

#85

Earlier quoted context omitted.

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.

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.

Re: Technical Debt Is Like a Tetris Game

#87

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…

[deleted]

Re: Technical Debt Is Like a Tetris Game

#88
post #48

> But technical debt becomes a problem when it gets out of control. Accumulating technical debt consists in piling up hacks on a piece of code, making it harder and harder to maintain. Every incremental change requires an intense reflexion and is more and more likely to cause regressions. Can anyone explain to me what reflexion means in this context?

variant spelling of reflection https://www.lexico.com/en/definition/reflexion

Re: Technical Debt Is Like a Tetris Game

#89
post #32

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.

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)

Re: Technical Debt Is Like a Tetris Game

#90

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 problem with this analogy is you don't necessarily take on technical debt when you make your technical decisions. Technical decisions only become debt when you have to revisit those decisions. You don't pay interest on debt over time. You pay interest whenever you build upon or modify the flawed code.

You can write the shittiest spaghetti code in the world, and if you never have to build upon - or touch it again - you took on zero technical debt.

In comparison, if you write just slightly flawed design, but build out your complete featureset based upon that flawed design, you could have mountains of technical debt.

I think a better analogy is building a structure. If your code is foundational, you better get that shit right. If you cheap out on a $20 part and have to replace it, but it's just a door knob, that's not too bad. But if it's under your slab on grade foundation you're going to pay thousands to dig it up and fix a $20 part.

Post reply on HN