
Technical Debt Is Like a Tetris Game - ingve
https://www.fluentcpp.com/2020/01/17/technical-debt-is-like-a-tetris-game/
======
newbkoder
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 need to understand how to pay it off. Similarly, if
you start a startup trying to find product-market fit before running out of
money, there is nothing wrong taking on technical debt to do so, as long as
you understand what you are doing.

~~~
Ottolay
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.

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

~~~
wnevets
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.

~~~
Buttons840
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.

~~~
wnevets
why not both?

------
slumdev
Software with significant technical debt is like a car held together with duct
tape and kept moving with WD-40.

1\. You wouldn't pay good money for it if you knew what was under the hood.

2\. Most mechanics are reluctant and embarrassed to work on it.

3\. Maintenance is going to cost more than you think, probably by a wide
margin.

4\. You wouldn't expect a major manufacturer to ship a brand new vehicle this
way.

5\. Nobody who knows what they're doing will ever brag about having a hand in
creating it.

------
lr4444lr
It's a good analogy, but if this is what it took to get through to your PM
what technical debt is, I think you should look for another job, stat. This is
a core concept anyone with that kind of power over your work hours should
understand deeply already.

~~~
knightofmars
>This is a core concept anyone with that kind of power over your work hours
should understand deeply already.

If the individual(s) with power over ones work have spent time writing code
then they will most likely have an understanding. If they haven't then it
often takes analogies of this nature to help them begin to understand what
technical debt is and how it has an impact on the future of the product.

------
luckydata
In this kind of discussions I read the same two or three positions rehashed
over and over again that are highly dependent on the situation(s) the wielder
of such opinions has found themselves in previously.

One thing I've never seen properly stated is the difference between technical
debt as usually described (building code that is doing the job but might not
be as flexible, easy to change or fix or might not account for all corner
cases appropriately) and then the kind of debt I've experience more often
which is "model debt". In the field of business applications, modeling a
problem correctly is 80% of the solution, and new companies usually do that
job very poorly. Over time as business experience accumulates, some of those
mistakes become evident. For example, how to model the identity of the users
of an application, that's where the most mindless decisions I've experienced
do the most damage. Let's say you assume the only type of user you're gonna
have belongs to "companies" and your customers are companies. Then you
discover those companies make heavy use of consultants or contractors, and all
of a sudden most of your management tools and UI doesn't quite fit. You can
hack it, but you end up with a large slice of your users having to manage 20
different emails to interact with your system. Just an example.

"model debt" is the most expensive and potentially fatal type of debt a new
piece of software can incur, and my suggestion is for every new project, focus
on building a real good model of what reality looks like before too many other
technical calls are made, or you're in for a world of hurt.

~~~
hammock
Model debt a new name for product-market fit? And you are describing pivoting
(maybe on a smaller scale)

~~~
luckydata
Not at all, reread what I wrote. It's getting the data model wrong for the
problem at hand.

~~~
hammock
You admit yourself the data model is ("80% of...") the product.

~~~
luckydata
and if you get it wrong and need to fix you're not pivoting, you're just
fixing bad design. "Pivot" means something different.

------
rubenbe
I tend use the "Leaning Tower of Pisa" metaphor. If it leans too much, the
tower will fall down. If it doesn't tilt at all, you won't sell tickets to
tourists.

The art is to find the sweet spot.

~~~
akerro
> If it doesn't tilt at all, you won't sell tickets to tourists.

I dont know about that... Eiffel tower is vertically straight and sells a lot
of tickets.

~~~
coldtea
That's because it's unique. The tower of Piza is like several other towers if
you take out the leaning part.

~~~
matteuan
It's beautiful and also a very important piece of Romanesque architecture.
It's probably the greatest example of circular bell tower. I'm sure that if it
was not leaning, it would be still very appreciated, maybe not by the postcard
turists but surely not considered "like several other towers".

~~~
coldtea
> _it 's probably the greatest example of circular bell tower._

Yeah, but in Italy those are a dime a dozen.

------
ronnier
Here it is:

> The analogy with technical debt is that each new fix or development is like
> a new block coming in, which you need to integrate with the existing code.
> If you hack it in a quick and dirty way, it’s like leaving holes in the
> Tetris structure: you’re making life more difficult down the line.

------
jashmenn
This same analogy was made by Eric Higgins in May in this popular post:
[https://medium.com/s/story/technical-debt-is-like-
tetris-168...](https://medium.com/s/story/technical-debt-is-like-
tetris-168f64d8b700)

------
thisisastopsign
Might actually be the best metaphor I've seen on this topic

~~~
heisenbit
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.

~~~
smitty1e
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.

~~~
jsight
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.

~~~
smitty1e
There is a certain subjectivity in play.

Is Duff's Device technical debt?

[https://en.wikipedia.org/wiki/Duff%27s_device](https://en.wikipedia.org/wiki/Duff%27s_device)

------
_asummers
Technical debt is risk. Just like in financial systems, taking on SOME risk is
how you make money, but you need to measure it and minimize it and be prepared
for if the risks taken all end unfavorably. This product risk (see also
dependency risk) is intertwined with the combined risk of other projects going
on, whether they're public relations risk, technical risk, staff risk, etc.
and taking on too much risk means you have too many flipped coins in the air
to count on them all landing favorably for you, even if they're weighted.

------
mobjack
Tech debt is more nuanced than explained by most analogies.

In reality there is a lot of tech debt you can get away for free and never
have to pay back. The code can be a mess but the functionality works and
doesn't need updating.

Other tech debt can infect and cripple a system if it isn't contained early.

If you demonstrate that you know how to prioritize the most important tech
debt then it is easier to convince management to work on it.

The concept of doing more work now to make future easier is universal.
Delivering on it is the hard part.

~~~
humanrebar
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.

~~~
jwr
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.

~~~
humanrebar
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.

~~~
thetedhogan
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.

~~~
humanrebar
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.

------
crimsonalucard
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 what you're gonna get."

I clearly know about how life and a box of chocolates can be random at times.
This is dead obvious information to the point of pointlessness. Yet in church
or in meetings you see people nod their heads in agreement as if something
insightful was said. Here's reality: Nothing insightful was said, the person
who was comparing life to a box of chocolates is literally mentally retarded.

Analogies are used to manipulate, not to inform.

~~~
engManager
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.

~~~
crimsonalucard
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.

------
zyx321
>Even if you leave a few holes in, it’s ok if you manage to have compact rows
above them that will clear out and allow to fill the holes later. This is
similar to technical debt, that is ok to build up if it’s under control and
you have a plan to pay it back later.

That's a very low-tier understanding of Tetris. At an intermediate level of
play, you'll want to deliberately leave gaps that you could clear at any time,
but you choose to wait until it is strategically advantageous to do so.

At an advanced level of play, you'll want to leave oddly-shaped gaps that can
only be cleared with a _Clever Hack_ which not everyone is able to understand,
let alone perform. (T-Spin)

Similar concepts do exist in programming, they are cynically referred to as
"Job Security" but I doubt that the author intended to encourage that sort of
behavior.

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

------
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](https://leanpub.com/legacycode)

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

------
jorblumesea
Types of technical debt are not made equal.

Implementation technical debt (the code) makes it harder for devs to work in a
given service, slows down velocity and increases the risk of bugs, but is at
least contained to a given service and can be rewritten as a known quantity.

Architectural technical debt will crush your product or your stack, often
quickly.

------
bobbytran
Technical debt for me means I will have a job fixing it at my current company
for many years to come (If I want it).

There will almost always be technical debt to some degree when it comes to
software. Nothing is perfect and we always dont have the time to create the
perfect fix..and instead need to just create something that works.

------
baud147258
I think my favorite analogy for technical debt is uncovered option, which,
compared to just technical debt, adds the information that it might or might
not be required to pay it back. Of course, to be able to use, your non-coder
interlocutor needs to know the relevant vocabulary.

------
slumos
It so happens I’ve been thinking a lot about the debt analogy recently and
decided that the simplest improvement is to think of it as an interest-only
loan.

Sure, that balloon is just sitting there, but every single day you don’t pay
it down, you are still paying interest. It slows you down when it causes
confusion, when it makes integration more difficult, and when everyone is
afraid to make improvements that might require changes to That Godforsaken
Class.

And if instead of paying it down, you decide to add more debt, then the
interest payments go up / the drag just gets worse.

And let’s be honest, arguing that tech debt is not bad comes up way more often
over adding more than deciding not to start paying down.

------
Twisell
Was waiting for the ultimate analogy : Plugin a tetris vertical bar is like a
carefully planned ahead refactoring. It's the most effective strategy as it
clean out 4 lines of technical debt in a single move.

------
m3kw9
Every project needs to treat tech debt differently, for example working alone
vs working with 20. How many requirements there are already, what state it was
in when you arrive to see the code(most devs are not the original coders). How
good the unit tests are, how proj Managment sees value in refactoring, company
run way if it’s a start up. Is very difficult to apply single analogy to all
projects. I see programming like life, it’s different every time so you have
to approach refactoring to fit the situation every time

------
chubot
I thought this was copied from my friend who wrote this article last year
which became popular:

[https://medium.com/s/story/technical-debt-is-like-
tetris-168...](https://medium.com/s/story/technical-debt-is-like-
tetris-168f64d8b700)

Although he references a 2017 article that says the same thing so I guess it
is a meme floating about.

~~~
dwd
Yes, I thought we'd had this discussion before...

[https://news.ycombinator.com/item?id=19353352](https://news.ycombinator.com/item?id=19353352)

------
JTon
> 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?

~~~
carlmr
In German it means to think about something. I'm assuming the author isn't a
native English speaker.

But to reflect on something exists in English as well, just spelled
differently.

------
deadbunny
Kelsy Hightower has used a similar analogy in regards to resource allocation
which covers a little on the tech debt side of things.

[https://youtu.be/HlAXp0-M6SY?t=654](https://youtu.be/HlAXp0-M6SY?t=654)

------
zorked
Technical debt: the horrible metaphor meant to explain a project to non-
technical people but that only technical people adopted.

And then everybody needs a better metaphor to explain the bad metaphor to non-
technical people.

------
k__
Like a tetris game where you (often) just see the top row of every column.

~~~
eropple
That would be 3D Tetris on the Virtual Boy!
[https://en.m.wikipedia.org/wiki/3D_Tetris](https://en.m.wikipedia.org/wiki/3D_Tetris)

(One of the better games on there. Not a large selection.)

------
m3kw9
Also to be fair, if you watch masters play Tetris they always build up “tech
debt” before clearing them all to the bottom magically

~~~
carlmr
They take pay day loans. Because they know they can earn more money in that
time. But they pay it back rapidly.

------
ubermonkey
LOL. I've actually often referred to shitty piece placement in my well as
"technical debt" when playing Tetris.

------
NeoBasilisk
I'm working on migrating a 10+ year old site into a new environment right now.
The technical debt is crushing.

------
crimsonalucard
Here's the insidious part of technical debt. There's two types:

Known and unknown.

If you are not knowingly accumulating technical debt, then 90% of the time you
are accumulating it unknowingly. This is the most insidious form of debt.

I have searched my entire career in software engineering for the solution to
unknown technical debt. The problem isn't just solving it, it's also clearly
defining what is happening to your software over the years even when you spend
the utmost care in not allowing technical debt to accumulate.

I think I sort of nailed down what's going on in a fuzzy way. I also sort of
have a fuzzy solution to the problem. Allow me to elucidate:

Eventually most projects will hit a point where you realize that your initial
design was poor. You are given a new feature and your old design is simply not
flexible enough to accommodate the change. In order to put the feature in, you
either do a massive rewrite or you hack it in.

In this way the technical debt that was accumulated unknowingly may force the
programmer to begin accumulating debt knowingly. In fact they often forget
about the unknown technical debt. They think that the only proper solution is
to contemplate between the cost of a hacky shortcut or a massive rewrite
without thinking about what caused the need for the massive change in design.
What exactly is the thing that is causing the "need" for the massive rewrite?

What's happening is, whenever you design something you are predicting the
future. You are assuming your design can handle certain current requirements
and future ones. However, the future is actually unknown, there is very little
chance you can ever predict the future in an accurate way. Thus by your lack
of ability to predict the future, your design will usually in the majority of
cases fail to predict the future and this problem will always occur.

That is all that is happening with unknown technical debt.

The best solution (not a full solution) to this is to design all your projects
with the maximum flexibility possible. That means every corner of your code
that can be factored into multiple modules or be easily factorable in the
future. By coding this way, you maximize the reusability and reconfigurability
of your code giving the best possible insurance for an unknown future.

If you heard of ravioli code, this is it. It has bad connotations but ravioli
code is my best known solution to unknown technical debt. Most people feel
ravioli code is hard to read or maintain... In a way it is, but the key here
is deal with the program in layers of abstraction. Your complicated ravioli
code of 100 primitives at the lowest layer must be able to "compose" into
higher level layers where you only have to deal with a manageable 20
primitives.

So the key isn't just ravioli code, but ravioli code with highly compose-able
modules you can use to simplify your code into layers. Think of it like a
slider between flexibility and simplicity. The higher the flexibility (more
primitives) the more complex your program is; the lower the flexibility (less
primitives) the more simple your program is... A good design is one where at
any moment in the projects life time you can move from layer to layer and
readjust the flexibility and simplicity of the program at will.

Unknown to most people there is a programming style that does the above almost
mechanically:

Typed Functional programming.

You may have done some FP and seen it get messy (especially with JS), but to
really see why this is the solution you should take a look at Typed FP using
the point free style. The point free style will help you understand the true
nature of a compose-able primitive.

------
NiceWayToDoIT
Great analogy!

------
louwrentius
Technical Debt is a bullshit term for people who want to get away with not
finishing their work and still want to sound like they are reasonable.

~~~
humanrebar
> ...people who wants to get away with not finishing their work

In my experience the people making the debt don't use the term as much as the
people pointing out the pile of ignored work.

~~~
louwrentius
Yes.

... or wants to get away with shitty work because they don't want to admit
they don't know how to do it right and be vulnerable ...

------
epicgiga
Analogies and metaphors are pointless. Whenever you use them, they'll just
respond with their own counter metaphors they pull equally efficiently from
their own rear ends, with a tone of indignation, implying you're trying to
trick them.

The only thing that works with technical debt is to aggressively uncover and
strike down any short term incentivisation from an organization perspective,
and to set in absolute concrete terms what the irrevocable code maintenance
policy is, and punish those who don't follow it. Everything beyond that, TD
measurement tools and TD backlogs (which you interlace at a minimum ratio) are
just details.

But the last thing that'll help you is talking about Tetris in front of your
client / PO / boss / whatever. Just call it "maintenance work". And if they're
hostile to even that, it means they're stupid enough that you can just do it
anyway and call it something else and they'll never know.

~~~
rightbyte
_" Just call it "maintenance work". And if they're hostile to even that, it
means they're stupid enough that you can just do it anyway and call it
something else and they'll never know."_

That is quite true. Unless you are working in a jira ticket sweatshop just do
it.

