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

101–110 of 122 posts

Re: Technical Debt Is Like a Tetris Game

#101

Post by engManager »

cle wrote: post #95
bcrosby95 wrote: post #90

Earlier quoted context omitted.

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…

This is exactly what the article says: > Technical debt consists in performing a fix or development in a quick and dirty way because it takes less time, even though it will make the code harder to work with in the long term. If you aren't going to be changing the code later, then writing a bunch of spaghetti code won't make it harder to work with in the long term.

How can one accurately predict that the code won't be changing in the future? If you needed to get something done once, isn't there a good chance that in the future someone else, including your future self, may need to rely on or modify it?

Re: Technical Debt Is Like a Tetris Game

#102

Post by engManager »

crimsonalucard wrote: post #22

Analogies create a false sense of meaning. Nothing new is gained other than an isomorphism. There is no logical transfer of new information because the analogy only works if you already understand both concepts. Additionally, analogies may over simplify concepts but usually people are too enamored by the isomorphism to really see it. Think about this famous analogy: "Life is like a box of chocolates. You never know w…

Isomorphism can yield eye-opening insights and inspire new behaviors. Drawing connections between similar ideas in different domains can be an enjoyable and creative mental exercise.

Re: Technical Debt Is Like a Tetris Game

#103

Post by smitty1e »

_ea1k wrote: post #64
smitty1e wrote: post #17

Earlier quoted context omitted.

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.

There is a certain subjectivity in play.

Is Duff's Device technical debt?

https://en.wikipedia.org/wiki/Duff%27s_device

Re: Technical Debt Is Like a Tetris Game

#104

Post by xwowsersx »

wpietri wrote: post #96
bcrosby95 wrote: post #90

Earlier quoted context omitted.

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…

The only code you never have to touch again is code nobody is using. In which case, it's like a corporation declaring bankruptcy: the debt becomes moot. Otherwise, you always have to deal with it eventually. Look at the Y2K problem. or how the 2038 problem is starting to crop up already, exposing significant levels of technical debt. https://twitter.com/jxxf/status/1219009308438024200 I also think technical debt does…

This is pretty amazing. From Wikipedia:

> Most operating systems designed to run on 64-bit hardware already use signed 64-bit time_t integers. Using a signed 64-bit value introduces a new wraparound date that is over twenty times greater than the estimated age of the universe: approximately 292 billion years from now, at 15:30:08 UTC on Sunday, 4 December 292,277,026,596.

Re: Technical Debt Is Like a Tetris Game

#105

Post by cle »

engManager wrote: post #101
cle wrote: post #95

Earlier quoted context omitted.

This is exactly what the article says: > Technical debt consists in performing a fix or development in a quick and dirty way because it takes less time, even though it will make the code harder to work with in the long term. If you aren't going to be changing the code later, then writing a bunch of spaghetti code won't make it harder to work with in the long term.

How can one accurately predict that the code won't be changing in the future? If you needed to get something done once, isn't there a good chance that in the future someone else, including your future self, may need to rely on or modify it?

It’s contextual. E.g. if you’re in a situation very similar to past situations where you threw the code away afterwards, you can be pretty confident that you’ll throw it away this time too.

Re: Technical Debt Is Like a Tetris Game

#106

Post by theptip »

bcrosby95 wrote: post #90
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 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 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.

I don't really agree with this view; it may seem pedantic, but I think it's better to consider that case as tech debt.

In my experience, it's incredibly uncommon to write code and never touch it again -- particularly if you elect to cut corners in the interest of getting something out the door quicker. That code inevitably either gets retired because it's not being used (your debt was forgiven), or gets built on top of (your debt starts to compound).

If you make a decision to lower the quality bar because "we are not going to touch this again, so it's not tech debt, so it doesn't matter", then I think you're fooling yourself. Instead, I think it's better to assume that you're taking on tech debt (you almost certainly are), apply all the best practices around managing that debt (i.e. catalog it, be aware of your overall debt level, and be aware of tech debt in critical systems), and be happy if your debt is later forgiven if you miraculously never need to touch that code again.

Maybe there's a narrow sense in which this position is technically/semantically correct, but I think more often than not, this position is going to hurt you more than it helps.

Re: Technical Debt Is Like a Tetris Game

#107

Post by wellpast »

Technical Debt is a term used by non-professionals as a euphemism for their own incompetence. I say this not to cut people down but with all due desire for us to get better at our work.

It's a lot harder for someone to say "I didn't know how to solve this" and much easier to say "It would take longer to solve it the right way." Because of this you should take claims fo "Technical Debt" with serious suspicion -- and given how fuzzy the general concept is and how enabling it is, I think the proper response is to find it useful far more for personal ego management than as a respectable tool for thinking about execution of software projects.

There is no innate conflict between solid decision-making in a software system and execution time. Generalizations take longer but generalizations or lack thereof do not imply sound architecture; this is orthogonal concerns. But solid execution (decoupled components) is a skillset question. In fact if you have the skillset it often takes longer to make a bad decision.

Technical Debt doesn't respect this (i.e. skills/mastery) and is only good for deflecting from our incompetence and thus keeping us from acquiring the necessary skillset.

Re: Technical Debt Is Like a Tetris Game

#108

Post by Animats »

This is an ad for a book on dealing with legacy code. The preview of the book [1] is more useful than the forced Tetris analogy.

Reading the table of contents of the book, it seems to assume everything is done by hand. There are some power tools for dealing with legacy code in C/C++, but I don't know which ones are any good and for what. A book which covered most of them and wasn't a fan piece for one tool would be helpful.

[1] https://leanpub.com/legacycode

Re: Technical Debt Is Like a Tetris Game

#110

Post by crimsonalucard »

engManager wrote: post #102
crimsonalucard wrote: post #22

Analogies create a false sense of meaning. Nothing new is gained other than an isomorphism. There is no logical transfer of new information because the analogy only works if you already understand both concepts. Additionally, analogies may over simplify concepts but usually people are too enamored by the isomorphism to really see it. Think about this famous analogy: "Life is like a box of chocolates. You never know w…

Isomorphism can yield eye-opening insights and inspire new behaviors. Drawing connections between similar ideas in different domains can be an enjoyable and creative mental exercise.

Yes in this sense it's good. But usually for analogies it's just relating one obvious fact to another obvious fact and the relations are so flush with each other that you fail to see that all you're being told are obvious facts.
Post reply on HN