
Three Kinds of Good Tech Debt - memset
https://engineering.squarespace.com/blog/2019/three-kinds-of-good-tech-debt
======
davnicwil
The article links tech debt to financial debt early on, and this is exactly
what the analogy is - it is best to be as literal as possible about it.

What is good debt? It's taking money from someone, promising to pay them back
more money in the future, and using the original money to make _even more
money than that_ , so both you and the lender profit.

Good tech debt is just the same. It's taking shortcuts now to save time and
get something shipped, knowing that it will cost you more time than you're
saving now to fix it later. But by shipping now, you ensure there is a later,
with a product that's out there and being used, a bigger team and therefore
adequate time and then some to fix the debt _and_ keep improving the product.
Everyone wins.

That's the theory anyway. I think mostly where it goes awry in the wild is
people forgetting the paying it off part. Part of this deal is you have to pay
back your lender - they have to win too. It's just easily forgotten because
_you 're_ the lender, so the incentives get a bit conflicted, and you'll keep
giving yourself more time. But if the lender ultimitely doesn't get paid back
and loses, you lose, and it's a bad debt.

~~~
TheLastPass
One important difference between tech debt and financial debt, is that if the
project you accrued a bunch of tech debt in gets killed for unrelated reasons
before it's completed, your debt is forgiven. You never pay it off, and you
never have to.

When you're validating an idea, don't worry about making everything perfect.
Worry about validating the idea. Once you're more confident that you're
actually gonna do it long-term, then it starts being more beneficial to pay
off the tech debt.

~~~
cactus2093
I think what you're saying is the more common use of "tech debt", basically
just using it as a synonym for "bad code". Don't worry about code quality,
figure it out later.

It ignores the stronger debt analogy -- sure, there is a high chance that the
idea fails. But if it succeeds and, all else being equal, you have taken on a
less tech debt to get there, you will be able to iterate on and grow it more
efficiently. So to the extent you're taking on debt, it should be an explicit
trade-off to increase your chances of proving out the idea. Which is not the
same as "don't worry about bad code at all."

From what I've seen, when it comes to talking about tech debt from an early
prototype, it's often an excuse/euphamism to be considerate to the people that
wrote it. The truth is often that it's just bad code due to them being
inexperienced or lacking the skill or discipline to write better code. Which I
don't mean as an insult, it seems like there's a strong inverse correlation
between the kind of person who's passionate enough about product over tech,
and is creative/naive enough to build and validate a brand new product, and
the kind of person who understands enough to architect a great system and make
the best tech debt trade-offs.

~~~
TheLastPass
I absolutely agree - that's the whole point of the article and my comment. If
you're in an experimental space, and 9/10 of your ideas are never going to
make it to market, I'd rather spend 1 units of time on each to figure out
which one's going to work, and then 20 units of time redesigning it the right
way (i.e. 21 units of time to be done), rather than 10 units of time on each
to make them all ready for production (i.e. 100 units of time to be done). But
those ratios will vary depending on how sure you are about what needs to be
done next, so yes - you've gotta weigh the cost / benefit.

------
julianozen
Two points I really enjoyed:

> Not Fixing All the Edge Cases

We’ve all seen bugs that occur so rarely, and fixing requires destroying some
part of the original design architecture. The ability to acknowledge these
types of bugs as not worth fixing is liberating.

> Err on the side of building too little because you can always build more
> later. Build things to be easy to throw away and replace;

I find developers tend to really dislike throw away code or temporary
solutions knowing they might break in the future. If the quick hack is well
documented, written in a very encapsulated and removable way, who cares about
removing it later.

~~~
gmueckl
Writing hacks and throw-away stopgap solutions is generally a bad idea in
reality. The only time when it can actually be allowed is when it it concerns
a feature that is a pure leaf in the system with nothing else built on top of
it. If you violate this rule and build other features on top of shortcuts, two
things will inevitably happen: you will have to replace the shortcut with a
proper solution eventually (it is only a matter of time) and by the time this
happens, the assumptions underlying the shortcut have implicitly been taken on
by the code depending on it. This means that you will have to review and
replace a lot of dependent code as well.

I have gone through that dance often enough. It ends up being more time
consuming than doing it right in the first place each and every time.

~~~
jamie_ca
Yes, it's more time overall, but that's not the point.

From the example in the article, if it would take them 2 months to build a
robust email delivery system or 2 weeks to put a temporary hack in place, it
could be worthwhile to the business to do the hack if it means they can start
user-testing 6 weeks earlier.

Also, if they're still in the product-fit stage of their business development,
they might find that the product isn't as useful/worthwhile as they thought,
and scrap it after 2 weeks testing. This would allow 6 weeks of overall
developer effort to be spent on another initiative.

Just because you know that developing throwaway code is waste, doesn't mean
it's necessarily a bad business decision.

~~~
gmueckl
Is it worth the while when you have to spend more than weeks to do it right
later? Again, in general it is not. You are citing a very, very specific
business reason as a justification. In 99% of all cases, no good business
reason exists to waste more money later. Essentially, this is what you are
asking. In your example, it's either 8 weeks total to do it right in the first
pass or 10+x weeks total to do it right later when you have the still
unquantified extra overhead of not breaking stuff that has been built around
the insufficient solution.

~~~
stingraycharles
You have to look at it differently: if you hack something in two weeks, you
will:

\- be able to switch to other, more important tasks more quickly;

\- allow the business to better discover what the _actual_ requirements are
while they have an MVP solution in place.

Resources are finite: you only have a limited number of engineers, and the
business needs to be moving forward. This approach allows you to do so, while
mitigating a lot of risks at the same time.

The costs are not lost: they bring back business value in terms of fast
progress, and mitigates risks.

------
theptip
I like the framing of tech debt as value-neutral; whether it's good or bad
depends on how you use it (just like financial debt). Of course, all else
being equal, you'd rather have zero debt.

One higher level consideration that's particularly relevant for early-stage
startups, is that you often simply don't have time to build the ideal "tech-
debt free" solution. Focusing on 80/20 solutions almost necessarily involves
adding tech debt. However, if you're mindful about where you take on tech
debt, and commit to tapering and then paying it down as your resources grow,
then you're more likely to avoid the debt spiral where your development grinds
to a halt, due to everything breaking all the time.

One other point I'd make is that a common form of "tech debt" for early-stage
startups is simply doing things that don't scale; it's often beneficial to
make your domain models flexible so that you can support one-off manual
interactions, for example if a new customer appears that requires it. Then
automate that thing and constrain the domain actions once you have collected
enough use-cases to know what makes sense to forbid.

~~~
WorldMaker
I like to point out as well that it isn't tech "debt" if there's no "IOU". For
instance, in the hard-coding example, it's conventional wisdom to avoid hard-
coded magic constants for a few reasons including it sometimes is hard to
figure out later why a magic constant was used, and in an if/else branch
situation like that maybe tough to figure out when you can cleanly refactor
those branches. If the case is well documented (it's the date of a given
feature release) and the code reasonably factored already (the "off" branch
isn't a ticking time bomb bug that needs to be removed after the date in
question), then it may be a code smell, but it isn't necessarily an IOU to a
future developer (such as yourself), so it isn't necessarily "tech debt", it
was just a trade off made at the time. Of course, if a future developer adopts
a hard linter rule against that sort of code smell, they may come to see it is
tech debt retrospectively, but that's also where the analogy starts to get
fuzzy.

(Pushing the analogy to a breaking point: Is adding a linter then, doing an
audit and depreciating assets for "tech taxes"? Come to think of it "tech
taxes" would be a fun alternative term to add to the "tech debt" family. "Hold
on, just paying my tech taxes; npm install, npm audit, and npm run lint.")

~~~
Gibbon1
I have a good example of no IOU. Friend 20 years ago worked on a content
streaming platform. They needed a dispatcher and someone wrote one in TCL in a
week. Just to get something working. And they never got around to replacing it
because it worked 'fine'. Turned out while everything else needed to be hyper
efficient and scale the dispatcher not really.

~~~
aeorgnoieang
An unexpected tech debt jubilee!

------
halfmatthalfcat
As I’ve gotten more senior in my career, I think one of the most enlightening
things has been anticipating debt before it happens (in
planning/architecting), acknowledging it when it does and then taking prudent
measures to minimize it and log it for future refactoring.

It’s also been funny seeing managers try to rebrand tech debt with other
business speak like “tech health”. Debt shouldn’t be a bad thing but one
that’s anticipated and respected.

~~~
ThePadawan
The term "debt" is really helpful. It also explains that while you can pay off
debts by taking on other debts, there is a good reason why this is illegal (if
done with money) in the real world.

Technical debt in your solution is fine. Running a Ponzi scheme in your
solution isn't.

~~~
dspillett
_> there is a good reason why this is illegal (if done with money) in the real
world._

Erm, it very much isn't illegal. At least not in most places.

Taking on fresh debt to pay off other debt is the very definition of a
consolidation loan which is perfectly legal in most, possibly all,
jurisdictions.

There are limits of course, like not using a loan to pay the deposit on a
mortgage, or simply not lending beyond defined means, but these are set by the
bank to manage their own exposure to risk rather than limits set by law. Such
limits are merely _encouraged_ by law, via regulatory limits on standing
capital compared to debt held and so forth.

~~~
joshlegs
also basically any 'balance transfer' option on pretty much every credit card
ever.

------
tams
Technical debt is a wonderful ally when building prototypes.

Imagine you are building a prototype and you are clever enough to only focus
on validating an idea. Having this focus you ignore all best practices and
maintainability issues you might tend to out of habit.

What you are likely to end up with is a functioning application that resists
change beyond its original goals.

And this is good. It lets you declare technical bankruptcy early enough to
avoid painful rewrites on a software that was not meant to exist for long
anyways.

~~~
spc476
As long as both sides (developer, management) are aware of this (he says, as
his "proof-of-concept" was installed into production directly by his manager
with no warning).

------
jakozaur
Tech debt is inevitable and is good as long as you keep the level of debt
reasonable, so maintanance cost doesn’t sunk too much of your dev time.

More good examples:

1\. Technology progress: Long time ago JQuery was the best for UI library.
Today you would use React or friends.

2\. Company stage. As a early startup you usually prioritize for speed and
validating hyphothesis. As you got a significant user base quality matters
more.

3\. Size of development team. With 5 or less developers having a monolite is
good enough. With 50 developers you likely take more advantage of microservice
architecture so each team can be decoupled and move faster.

~~~
purple_ducks
> With 50 developers you likely take more advantage of microservice
> architecture so each team can be decoupled and move faster.

Microservices aren't magic. There still has to be a contract between the
services. Microservices are best when they are something which need to be
scaled independently of the rest of the system.

------
stevetodd
I prefer the definition of technical debt being an uncovered call option: at
some point the debt will come due and you don’t have anything in place to
mitigate the issues it will cause and may not know when it will come due. This
debt might look like a manual deploy process, a lack of automated testing,
insufficient alerting, no rate limiting on public endpoints, etc. These are
things that are fine and then when they’re not, they interrupt the schedule
and require urgent and immediate attention.

Bad architecture can cause urgent issues and it can also impact new feature
development. The debt is a barrier that makes new features either take much
longer than they should or make them just infeasible from a business
standpoint. This can exist in both technical architecture or information
architecture (i.e. you chose the wrong model and now it’s too engrained across
everything to change).

------
munk-a
Tech Debt is never good, but it can be acceptable in exchange for a greater
gain.

So, just like this article's opening:

> Financial debt isn’t universally reviled in the same way. Your friend takes
> out a mortgage to buy a house and what do you say? Congratulations!

Except it is universally reviled, no one wants debt - they just accept debt in
reasonable quantities as a way to efficiently get things done.

I think, in particular, the success of not-quite-agile-but-similar business
practices has confirmed this, plan carefully and evaluate business needs, then
get it done in a way that's fast and leaves you relatively free of debt -
don't plan for everything. So don't get stuck in analysis paralysis trying to
build the perfect things - and don't just code with no thought of the
future... it's a difficult road to follow.

------
nicoburns
I'm not sure if I'd even consider these things tech debt. I tend to
distinguish between:

1\. Unfinished/unpolished implementations 2\. Implementations that are
architectural flawed, such that fixing them requires throwing away the
existing code.

Issues in (2) are a lot more problematic than issues in (1).

~~~
mbostleman
Yea, I was going to say the same thing. Work undone as part of prioritization
is not debt. Debt to me is causing more work than it would take otherwise so
that less work can be done now (or because the developer / architect just
doesn't know any better). Using a switch statement instead of a factory. Using
role based auth instead of attribute based. Things like that.

The problem is, the debt metaphor is not being applied correctly. Not doing
future work now does not take on responsibility for the future work - so it's
not like taking a loan. Doing work in a way that commits the team to extra
work that didn't exist before - that's like taking on a loan. For instance, I
don't want to do this 80 points of work now, so I'm going to ship the same
requirement by doing 40 points of work on a solution that will take another 60
points to get to the original 80 point solution which is the way we know we
have to go long term. I just borrowed 20 points on behalf of the team.

------
onemoresoop
I'm not sure how this classifies as tech debt, but in my experience the worst
type of tech debt is found in parts of a system that is relied upon and whose
business logic has become unmaintainable, is too complex/poorly understood and
is not possible to throw away as too many things depend on it. Also usually
whose initial creator is long gone, the documentation is conflicting with the
code implementation. This kind of debt causes eternal confusion and constantly
lowers the productivity of the team. In cases like these, workarounds are
created and more tech debt accrues on top of it that is even harder to reason
about. Nobody sane can fix a mess like this and the only hope is death of the
system or complete overhaul.

------
dsjoerg
Another kind of good tech debt I was hoping to see here is when something is
built somewhat poorly/quickly because it will give you _information_ that you
need to have in order to know whether it's worth building it any better.

~~~
notabee
Prototypes are very valuable as long as you know to throw them away and build
the real thing. The unfortunate aspect of many business environments is that
low knowledge outsiders see something "working" and demand that it be thrown
into production for [insert business speak reasons]. Tech debt isn't always a
decision made by the subject matter experts.

------
nerpderp82
If you aren't spending tech debt, you don't have a sound monetary policy. Zero
tech debt is not a healthy goal.

~~~
wellpast
Unlike financial debt, which has a clear quantitative measure, Tech Debt is an
incredibly fuzzy concept to the point of being useless for anything other than
covering one's ass. We can do better as engineers than resting on such fuzzy
thinking.

~~~
Raidion
But that's the point. It is a fuzzy thing. Software is built on business
priorities, not technical ones. These align a decent amount of the time.
Spending the extra time and money to set up tests is very much worth it.

Is it worth implementing a cache layer in a system? One on hand, you have a
better system that can handle more load, on the other, you've spent time that
could be spent doing something else. Your systems will almost always have
limitations, it's important to understand these and communicate them well.
Tech debt should be managed so it doesn't tip over and cause issues. Really
good devs and dev managers develop the eye to see when that's about to happen
and make sure they convince product that you need to pay that down soon.

~~~
wellpast
> Is it worth implementing a cache layer in a system?

This isn't a "Tech Debt" thing. This is a feature/scoping thing. Does my
system need to handle 1M concurrent users? If so, support that. If not, don't
support it.

But we don't need the absurd concept of "Tech Debt" for effective analysis. We
can be specific. We can be clear. Does my system need to support low latency
in the face of 1M concurrent users? Yes or no. Now proceed.

"Tech Debt" is such a ridiculous dodge to otherwise avoid real analysis, real
work, real clarity.

~~~
aeorgnoieang
I think it's pretty clear that there are often, clearly, no right answers to a
lot of questions.

The answer to "Does my system need to handle 1M concurrent users?" could be
"Yes", "No", "Not for the foreseeable future" or even "I don't know".

Given that 'debt' is a way to, in effect, allocate (possible) future resources
today, it's pretty _clear_ why it's valuable, especially in the face of
uncertainty.

~~~
wellpast
What you're saying is no one has perfect forsight.

That's a given.

You don't need the notion of "Tech Debt" to deal with that.

It is a complete given at any given time, during any given sprint, that all
the features in the queue are ASSUMPTIONS.

That's just a tautology.

"Does my system need to handle 1M concurrent users?"

Maybe you answer Yes or maybe you answer No, but you have to answer something
to make decisions about the work ahead of you.

The worst possible place is to be in the fuzzy middle saying fuzzy things like
Tech Debt and rolling along fuzzily.

Many teams -- especially teams that love this term "Tech Debt" \-- do exactly
this.

But they are willfully navigating in the dark and "Tech Debt" is just a term
that makes one feel psychologically okay with their ignorance.

But it's euphemism, that's all it is. It does not aid in rational navigation.

------
losthobbies
Nice article.

The code review articles are good too:
[https://engineering.squarespace.com/blog/2019/code-review-
cu...](https://engineering.squarespace.com/blog/2019/code-review-culture-
part-1) [https://engineering.squarespace.com/blog/2019/code-review-
cu...](https://engineering.squarespace.com/blog/2019/code-review-culture-
part-2)

------
momokoko
I've always believed that "debt" is not a great term for this. Because it does
not really apply to financial debt.

Financial debt is often repaid simply by bringing in more revenue because of
the benefits gained from bringing on the initial debt. The only risk involved
in the debt is that there will not be enough money to pay it back later. It is
a very predictable and obvious issue.

Technical debt is closer to educated gambling. You are taking a risk that the
shortcuts you are taking will not pop up and hurt your company before you fix
them. You are essentially saying, "We know this is a problem, but we are
estimating that it won't hurt us for the foreseeable future".

The better analogy to technical debt is investing. You are getting a certain
percentage increase in productivity(a dividend or other capital gain) for the
(hopefully low risk) gamble that your investment will not have a problem and
wipe it out or simply cause significant losses.

Developers typically do not like this because when the inevitable few cases of
these "investments" turn bad, they tend to be the ones that take on the
majority of the blame.

~~~
k__
To me they even sound the same after you explained them.

Not being able to pay back money sounds like the same as not being able to fix
bugs.

------
jboy55
Tech Debt, to me, grows with every line of code you write that didn't replace
a line of code. Consider how many projects start with the idea, 'I'll rewrite
this and get rid of the tech debt'.

First, If the original code isn't deleted, you've added to the tech debt. Now
every new engineer will need to learn two chunks of code, and every existing
engineer will need to support both.

Second, unless you've had a major epiphany between the old code and the new
code, you're more likely to run into the trap of the first example. Major
epiphany's could be, 'wow, we really didn't need all of that extra stuff', or,
'we've duplicated so much code, we should re-organize this all'.

I've been at plenty of companies where you have to understand that the Perl
code is really old and these components use that, the Mason rewrite was 80%
done and is over there, the Next Gen code was in Ruby these components do
that. But now, we're embarking on a new Node/React project to replace all of
it, finally going to get rid of the tech debt! (Said with no sarcasm)

~~~
theturtletalks
If tech debt is inevitable, what’s the solution? Good internal documentation
and rewrites every few years?

~~~
rickbad68
a practice of constant refactoring..

------
vinay_ys
Nicely done. Good to see an engineering blog acknowledging tech debt openly.

I'm with you all the way until the last paragraph which short-changed the
conversation a bit. Quoting a few lines to respond below:

>> Build things to be easy to throw away and replace; it’ll make your code
more modular.

One valid strategy to manage debt is to declare bankruptcy or amnesty on debt
– that is throw away the code (because this code is no longer needed). In
domains where this possible, definitely use it. But in most real-world
touching software domains this is not likely possible.

>> Good tech debt has clear, well-known limitations. Document these in code
comments, READMEs, FAQs, and conversations with the people who’d care.

Doing tech debt accounting in a more formal manner is required to
intentionally take debt. In the locking example, it is a design debt (not just
a code debt). If the debt isn't document well and then it can become a ticking
time bomb to be tripped by a clueless developer later.

------
HelloNurse
The defining characteristic of technical debt is attempting to avoid paying
it, taking shortcuts that create "interest" in the form of increased effort
and cost; it's always bad, but depending on timing and costs it can range from
a "correct" minimum cost choice (e.g. badly tested truly throwaway code) to a
stupid mistake to an existential threat.

Technical debt is a close relative of externalization (I save time, you waste
time) and of mistakes that result from incompetence rather than from haste and
shortsightedness.

All three sections of the article, instead, describe healthy planned evolution
from a decent provisional product to a better one, with solutions that might
be rough but not necessarily bad. In other words, a clickbait title for sound
(but maybe unrealistically mature) examples of properly pragmatic project and
product planning.

------
cjfd
@1: One could also have automated tests instead of scaffolding.

@2: Sure, but this it not really technical debt. It is the wise policy of not
immediately writing code for the most general case. If one writes several
instances of this it would lead to code duplication that would need to be
refactored immediately.

@3: Careful with this one. The thing is that the thing you call an edge case
might have the more proper name of 'bug'. If you deliberately leave in bugs at
the time of writing the code it can lead to very difficult to estimate
'stabilization time' at the point where the code is supposed to go into
production but is not quite reliable enough. It becomes somewhat difficult to
explain if that 'stabilization time' turns out to be months or even as much as
a year.

------
ChrisCinelli
> Good Tech Debt Is Intentional

When it comes to accelerate development in my opinion this is most (80/20) of
it.

------
jkoudys
Love love love this article. I'm so tired of hearing lazy, unskilled,
disorganized, mismanaged, etc. companies handwave the shit they write as
simply being "tech debt". Sticking 50ms waits throughout your code, because
you're not good enough to figure out how to actually trigger your action from
an event or await something completing isn't "tech debt". Maybe hiring people
not good enough to figure it out could be considered that from a higher
level..

If we are going to allow the tech debt metaphor to continue, too much of the
debt I see is the equivalent of a pay-day loan.

------
jdance
I take a chance and say it right out: Fix some kind of image library
functionality! As a customer who's also used Wordpress (everyone?) its just
madness that I have to keep originals on disk somewhere to post it onto
another page. I can hardly figure out how to download the full size original
to be able to upload it again. I ask you humbly, please, you have the power to
improve my life!

If you want me to stay on topic -- this is the worst wasted time debt
Squarespace has to me as a customer :) code wise the product is really solid
so their philosophy is obviously good!

------
opportune
I think that "Good Tech Debt Is Intentional" is the key point. If you are able
to recognize something as technical debt as it is created, you can also more
effectively plan for paying it down later, and note what you think the
solution would be at a high level. The real issue with tech debt is not that
it exists, but that people wait too long to pay it down, and then end up
taking more dependencies/making more technically bad decisions to deal with
the tech debt which just makes it even harder to fix.

------
another-dave
"Financial debt isn’t universally reviled in the same way. Your friend takes
out a mortgage to buy a house and what do you say? Congratulations!"

There's an implicit assumption there that your friend can afford the purchase.
If banks did no credit checks & your friends were impulsive & broke you might
try to talk sense into them instead.

Maybe we need to store PM's technical debt for 10 years and perform a credit
check when they say "I don't care, just ship it & we'll clean it up later"!

------
Shinchy
> Financial debt isn’t universally reviled in the same way. Your friend takes
> out a mortgage to buy a house and what do you say? Congratulations!

We do say Congratulations! - we say well done on finishing the project you
were working on.

I do agree with the part on not putting too much worth on edge cases, however
the biggest issue for me with Technical Debt is the increased time it often
leads to in further development. So I wouldn't say it's something to
completely ignore.

------
wellpast
I'm going to take a more controversial position here, and it bothers me that
it is even controversial.

The very concept of Tech Debt, though prevalent, is pernicious, because its a
concept that is far, far, _far_ too fuzzy and therefore can -- and _is_ \--
always applied as a convenient narrative to explain away mistakes, process
deficiencies, bugs, etc rather than a true conceptual problem-solving tool
that aids in optimizing the software development process. In short, "Tech
Debt" is a euphemism for incompetence.

We can see this play out in this post, which covers "3 kinds of good tech
debt.

1) "Scaffolding" ... what the author describes here is good ol' fashion
Prototyping, aka Learning. No invocation of a fuzzy concept like "Tech Debt"
is needed here. You don't know something, so you go and learn what you need to
learn. Learning takes many forms. In this case, it is product understanding --
and this author reaches for prototyping in particular and calls it
Scaffolding. Why a new term? Why obfuscate, why fuzzify? Because that's what
Tech Debt is good for: fuzzy thinking. If we move to more clarity we can be
specific and we can take specific actions to optimize: here, maybe or maybe
not prototyping isn't the most efficient way to learn what is needed: often,
wireframes shown to customers will suffice. There are plenty of ways to skin
this once the framing is clear.

2) "Hardcoding" Again, no fuzziness is needed here. Developers have a fetish
for fully flexible and feature-rich subsystems and we tend to call anything
else a pejorative like "hard-coding" but that's a psychological problem in us,
not a technical or process problem. We already have a clear framework for
talking about this and it's called feature Scoping. There are, again, plenty
of ways to skin this cat, but the short of it is - if you can understand what
features you are interested in with clarity then you can build a system whose
flexibility is in accordance. This isn't a fuzzy "Tech Debt" thing. If you
_only_ need feature X now and going forward, then build that - and call it
something pejorative like "hard coding" if you want: I call it being rational.
But bringing in a fuzzy term like "Tech Debt" helps nothing here. Only
confuses.

3) "Not Fixing Edge Cases" This one is the worst of all. By using a fuzzy term
like "Tech Debt" we're able to completely alleviate our responsibility. And
start down a path of extreme cost and pain. Here, he wants to avoid having to
implement correctness because it would cost too much. The example is a good
one: it reflects a pattern I've seen over and over again. And unfortunately
I've seen the same choice this author makes -- and the terrible downstream
cost it creates, as well. By avoiding implementing a correct solution (by
purposefully shipping a race condition) he is not being clever, he is being
irresponsible. If this sounds draconian, let me explain further. Perhaps he
finds, as he mentions, that in production this is inconsequential. Okay,
great. But first thing to point out is that most likely it will become an
issue as the system grows and when are you going to notice that? Are you going
to go build monitoring to make sure that this "effective correctness" holds
over time? Of course not, that's _more_ work. But even if you are happy with
his choice here, there's a bigger issue. He has chosen to build a system with
transactional needs on top of an eventually consistent/NoSQL solution. From my
experience, it's rare that you have just one feature like his that needs
transactional correctness and that is it. _Tomorrow_ , _next week_ , _soon_
\--he and his team are going to find out that they need another transactional
capability and then they are going to be right back where they started: having
to ask a question, do I slack off here, as well? Again -- we've created cost
for ourselves by forcing us to ask, should I ship a bug in _this case_? One
might say this is what "Tech Debt" lets you do! It lets kick the can down the
road, save you some time now... But I do not buy it. I've seen this exact kind
of choice made plenty of times and the can always comes back next week, next
month and the tax you pay for not getting right is immense. "Tech Debt" here
is simply letting us avoid responsibility, avoid having to understand the
needs of our overall system. The cost of getting transactions right/correct is
not even that high if you face it squarely and truly make sure you need NoSQL
and in which cases. What's happening here is not clever process optimization
but inexperience. And if not inexperience, laziness (not the good kind).

The concept of "Tech Debt" is awful. And always ends up being a euphemistic
excuse. I've never seen the idea of "Tech Debt" help the actual process and
technical quality of things. I've only ever seen it give developers an excuse
for inexperience, laziness, etc. I don't mean to denigrate here -- I mean to
challenge and ask for us to be more intentional, clear, and frank in our work.
"Tech Debut" is fuzzy thinking and fuzzy thinking isn't much good for anything
other than excuses.

~~~
vinay_ys
I think you are being overly harsh. Since you seem to take issue with the term
tech debt as a fuzzy term, I suggest you read up on the research on this
matter (Researchers talks and paper published by
[https://sei.cmu.edu](https://sei.cmu.edu) is a good starting point).

A developer aiming for technical supremacy for its own sake isn't useful in a
real-world business scenario. I've seen enough technically superior software
products utterly fail in the market due to poor product-market fit iteration
speed.

Tech debt isn't a choice an individual developer should make. Tech leaders at
the top of any evolving software based product/service should deeply
understand the pros and cons of the concept of tech debt and then decide to
use it as a strategy lever.

They will have to make appropriate choices w.r.t people and process that is
right for their company to leverage tech debt.

This will reflect in the technical architecture of the systems as well. There
will be different layers of the stack where tech debt can be more vs less.

There are automated measure that can keep you informed if the tech debt is
exceeding to the point where it is becoming a net liability (vs being a net
asset as a strategic lever).

It may be true that many organizations use the term tech debt very fuzzily and
don't really give it conscious and serious thought and put effort to
structurally leverage it. In this, your rage against may be justified.

For those who are interested to read more on tech debt should visit these
links:

[https://martinfowler.com/bliki/DesignStaminaHypothesis.html](https://martinfowler.com/bliki/DesignStaminaHypothesis.html)

[https://martinfowler.com/bliki/TechnicalDebtQuadrant.html](https://martinfowler.com/bliki/TechnicalDebtQuadrant.html)

[https://2019.techdebtconf.org](https://2019.techdebtconf.org)

~~~
wellpast
> Researchers talks and paper published by
> [https://sei.cmu.edu](https://sei.cmu.edu) is a good starting point

Please link to a real paper that explores Technical Debt. This is just the
link to SEI's home page. I'm looking for clarity, not hand waves.

> A developer aiming for technical supremacy for its own sake isn't useful in
> a real-world business scenario.

You're straw-manning.

We're not looking for technical supremacy at all. (See my point #2 and my
emphasis on brutal practicality.) We are looking for business optimization and
all of the pragmatism that comes with that.

My objection is to using a dodgeball term like "Tech Debt", which in no way
helps to carve a pragmatic path forward.

It is akin to hand-waving. If you move forward with any degree of efficiency,
it will be in spite of your use of the fuzzy notion of "Tech Debt". You can do
just as well without this (non-)concept.

I would call this "My Thesis" but that acts as if the burden on me is to
justify my objection.

The burden is on whoever introduces this silly "Tech Debt" notion to 1)
clarify what exactly it means and how to measure it; and 2) give a model in
which the measurement can correlate with an improvement to the software
process.

Otherwise you're just talking Santa Claus.

I have yet to see anything close to that kind of clarity when one discusses
Tech Debt. There are a dime a dozen posts on "Tech Debt" and if you dig just a
little you'll see that it is nearly always used to avoid clear analysis.

To be fair, clear analysis is hard, so I can understand why people give up and
take the easy path. But let's call the spade a spade. "Tech Debt" is a dodge.
It's not a constructive tool.

Your links are not helping your case either.

Fowler's writing explicitly makes a distinction between quadrants of Tech Debt
and the only one he calls "Prudent" is the panic "We must ship now scenario."

If this is the only form of "good" Tech Debt, then my case rests completely.

Because all that is being said then is that "I literally have no idea what
situation my code assets are in but I have to ship now, so let's go with
whatever's on disk!"

Again, this is fair business. Anything is fair business.

But this is certainly a position of ignorance and not a position of strategic
choice. So if can admit that "Tech Debt" is simply "Ignorance", then we are
all in agreement.

Admitting ignorance, incidentally, is the only way an experienced practitioner
can emerge and reduce the likelihood of being in such positions to begin with.

Matters are even worse. Besides "Tech Debt" being a useless concept. For the
_individual_ it creates no clarity, no admission of deficiency, and no
incentive or need for growth.

~~~
vinay_ys
>> The burden is on whoever introduces this silly "Tech Debt" notion to 1)
clarify what exactly it means and how to measure it; and 2) give a model in
which the measurement can correlate with an improvement to the software
process.

I would highly recommend this book:
[https://www.oreilly.com/library/view/managing-technical-
debt...](https://www.oreilly.com/library/view/managing-technical-
debt/9780135646052/)

Also, read the papers presented at this conference series.
[https://2019.techdebtconf.org/#program](https://2019.techdebtconf.org/#program)

~~~
wellpast
Thanks for these links. I read through the book's examples of Tech Debt.

The book enumerates some examples of failed software projects and calls their
failures "Tech Debt".

I have two issues with this.

The first is how fuzzy this still is. This term is thrown over all of these
various kinds of failure. And the examples are also quite varied - most are
phrased as mere symptoms of failure not root causes, which gives us little
insight.

The bigger problem I have is that these examples are retrospective.

If Tech Debt is simply a term for "mistakes I have made", then by all means
use it -- obviously in this form it has no strategic/constructive value.

But the way I've seen it typically used is for people to act as if it is akin
to real debt, consciously acquired.

"Oh I didn't make this transactional because Tech Debt."

Etc.

And indeed if Tech Debt as a concept is to have any value it should be able to
be used this way.

But my objection is that there is no way it can be used as such, because it is
far too nebulous a concept to have any navigational benefit.

It gives no helpful path forward. It is purely a euphemism for mistakes.
That's how I've seen it used universally, at least.

------
dredmorbius
JS-mandatory text-only blog posts are bad tech debt.

[https://outline.com/fH9GzD](https://outline.com/fH9GzD)

------
rkagerer
Great article.

But the only reason their approach to the "11 item" edge case works is that
they manage their own data. So they can monitor and might potentially cull
manually if it became necessary (eg. What if the race condition caused more
than 11 or a future codechange elsewhere stumbles on it).

In a non-cloud product where the cost is higher for a vendor to come verify
and fix data, this wouldn't fly.

------
sorokod
_So we asked ourselves, “What’s the simplest thing that would make the editor
useful to our coworkers?”_

To me, technical debt is associated with a sense of regret. The example in the
quote above doesn't have that, perhaps that is what makes it the good kind.

~~~
wellpast
Perhaps this isn't "Tech Debt" at all. Perhaps this is a long understood,
well-known activity called Prototyping or Learning. Perhaps the concept of
"Tech Debt" is just fuzzy thinking.

~~~
sorokod
Yes, something like that. When a suboptimal solution serves a strategic
purpose it is not TD.

------
enginaar
I'm failing to see the point in calling a technical dept "good". As far as I
can tell from the article, the author is measuring 2 possibilities of
technical dept and choosing the one that incurs the least dept. I can see how
good a decision this is but I don't see how this makes the dept good.

~~~
kevsim
> I don't see how this makes the dept good

Time to market, for one. If you get the feature out faster to your customer,
eating some debt can be worthwhile. This article is merely providing a
structured way to think about the debt you're taking on.

------
_bxg1
This is a good take.

------
anonygler
> if now >= NEW_CONTENT_DATE

No canary? Tsk tsk.

------
louwrentius
This was an amazing article.

------
mlwhiz
Sometimes going in a Hardcode way is much better than going around in circles
to get the perfect code. Saves time and is more intuitive.

------
somesortofsystm
No, and no, and no.

Just fix it. Repeat until completion.

