Author here, thanks for sharing! Happy to answer any questions!
Technical Debt Is Like Tetris
21–30 of 32 posts
Re: Technical Debt Is Like Tetris
#22It's a great analogy, and it reminds me of a model I like to use when thinking of technical debt: Get a jar full of jelly beans, and every time you have to make a compromise (e.g. adding some hacky code or introducing some problem you'll have to fix later) take a bean out of the jar. If it's a terrible hack, then take out several. For the first few jelly beans, you won't even notice the change to the jar, and the fir…
It's weird when you are part of a larger org; you still worry about technical debt as a team, but you have to also deal with, like, institutional technical debt.
Realistically, something like 10-20% of the engineering resources at a company like Google or Microsoft are going to service technical debt at an institutional level. Sometimes it is literally all an engineer does, like maintain a deprecated system that can't be turned down for five years or a team migrating large systems from the old and busted to the new hotness, sometimes it's just the tax on engineers doing other projects to work around the technical debt. It's just what happens when you have tens of thousands of engineers working for decades.
Re: Technical Debt Is Like Tetris
#23Is tech debt subjective? I've worked on different teams that call anything from wrong grammar in comments to incorrect capitalization of a var name tech debt. Wondering if it follows that more code = more debt because more people have opportunities to disagree about how something was done. Asking for a friend.
If it causes a problem where solving the problem once doesn't solve it in the future, and where the fixing is a total waste of life that doesn't teach you anything, or where an easily solvable problem is compensated for in higher level abstractions, it's probably "tech debt".
Personally I would consider a stupid name or out of place capitalization to be tech debt of it leaks out into config parameters or something such that it can confuse more than just the people looking at one isolated chunk of code.
(Or call it "tech necrosis", because americans with college debt tend to view "debt" as an inevitability in life and that's not a helpful attitude for getting stuff done)
Re: Technical Debt Is Like Tetris
#24It's a great analogy, and it reminds me of a model I like to use when thinking of technical debt: Get a jar full of jelly beans, and every time you have to make a compromise (e.g. adding some hacky code or introducing some problem you'll have to fix later) take a bean out of the jar. If it's a terrible hack, then take out several. For the first few jelly beans, you won't even notice the change to the jar, and the fir…
If the jar is 10% empty presumably you want to multiply the estimate by 10/9.
Re: Technical Debt Is Like Tetris
#25Is tech debt subjective? I've worked on different teams that call anything from wrong grammar in comments to incorrect capitalization of a var name tech debt. Wondering if it follows that more code = more debt because more people have opportunities to disagree about how something was done. Asking for a friend.
I like to compare the nominalization of technical debt to taking out bank loans and investing in the open market.
All tech debt, like loans, have some interest rate. Some debt has a great rate, say 3%, and other debt has unmanageable rates, say 18%. Once we attain some stability to begin paying down our debt, it's necessary to pay down the higher interest debt (architecture, libraries, speed, etc.). Once we whittle our way through the high interest bearing debt and we're left with low-rate rate, it may make sense to continue investing new capital into the market (novel product/feature development). The new investment could return 8-10% annually, which garners higher annual net returns (10-3 > 3) than continuing to pay down all debt.
TLDR: Some technical debt affects critical systems and flows and need to be paid down immediately. Some technical debt may be cosmetic or semantical, therefore less critical and can continue to accrue interest.
Re: Technical Debt Is Like Tetris
#26I recently needed an HDMI cord for a monitor and realized that my cord drawer was accruing technical debt. Whenever I am done with a cord I just throw it in there... it gets all tangled up with all the others. When I inevitably need one of those cords I impatiently pull it out and it makes all the other cords more tangled. Here I am needing an HDMI cable that won't just come out easily, I have to pay off my past lazi…
Wow. I never thought of clutter in the home as technical debt, but it's as similar as you describe. That really makes me see home organization in a whole new light.
Check out Mari Kondo's show on Netflix! It is a guide on managing organizational debt in your home!
Re: Technical Debt Is Like Tetris
#27One thing I like about this analogy is the implication that some debt can make it harder to pay off other debt. It definitely operates in higher dimensions than just the two. I'm not sure about the implication that delivered features don't have a cost.
Re: Technical Debt Is Like Tetris
#28This might be captain obvious to some, but I think it still needs to be said: Technical debt is like any other debt and needs thorough analysis and some business strategy applied before things can and do get better.
You're saying tech debt is a business strategy problem?
I'd say so. If you aren't assigning your teams time to review the mistakes of the past and actually fixing them, then you're not employing a strategy for success.
Re: Technical Debt Is Like Tetris
#29Author here, thanks for sharing! Happy to answer any questions!
Great analogy, and very thought provoking.
Had me thinking about different strategies you might use in Tetris and how they mirror development.
For example, when you do the big setup to drop a vertical 4x1...and it doesn't arrive.
Classic case of Yagni or Premature Optimisation leading to technical debt.
Re: Technical Debt Is Like Tetris
#30Is tech debt subjective? I've worked on different teams that call anything from wrong grammar in comments to incorrect capitalization of a var name tech debt. Wondering if it follows that more code = more debt because more people have opportunities to disagree about how something was done. Asking for a friend.
Do you disagree with the notion that misspelt comments or variables is technical debt, though? Personally I would consider it a light form of technical debt simply because it makes the code slightly harder to read.
It not only makes it slightly harder to read - it can also make it slightly harder to modify.
For example, if all variables in a code base are camelCase but one variable StartsWithUpper, chances are every time you reference that variable in a future code change you'll call it startsWithUpper and then hit an error (depending on the language, either at compile time or run time), and have to go back and fix it. So it adds a little time to development in that way. Negligible, but non-zero