
Using Technical Debt in Your Favor - treyhuffine
https://levelup.gitconnected.com/how-to-use-technical-debt-in-your-favor-98bae475ba68?ref=hn322
======
zeroxfe
Managing technical debt is one of them most important parts of engineering.
When you're resource constrained, which is almost a given in the real world,
you need to think carefully about what kinds of debts are worth accruing, and
what kinds are absolutely not.

I think this is both an art and a science, and the right balance comes with
not just engineering experience, but also domain experience, team
maturity/talent, market/competitive pressures, leadership, and culture.

There are so many factors involved that it's not surprising so many projects
accrue horrible debt.

~~~
peterwwillis
Are you talking about software engineering, or engineering engineering?
Because I don't think building engineers create technical debt.

~~~
pjc50
Buildings can _definitely_ accumulate technical debt when they're put through
a series of changes of use over time. It manifests as odd cable routing,
inconsistent floor levels, repeatedly moved doorways, obstructed windows, etc.

~~~
pm215
The UK houses of parliament are a good, if perhaps extreme example of that:
[https://www.theguardian.com/news/2017/dec/01/a-tale-of-
decay...](https://www.theguardian.com/news/2017/dec/01/a-tale-of-decay-the-
houses-of-parliament-are-falling-down)

They have now finally decided to move the MPs out so they can do the
refactoring they've needed to do for years...

------
humanrebar
Sure, and credit cards can be a good thing, too. The problem is that most non-
technical and formerly-technical project managers just charge everything to
their credit cards and don't even know they _own_ debt and are making interest
payments on it.

When that's the level of awareness the average development team is dealing
with, there's limited practical purpose in exploring the nuances of healthy
debt management. It's more useful to talk about technical debt like
nutritionists talk about empty calories and transfats.

~~~
rebeccaskinner
I see accusations of this a lot, and honestly I just really wonder what the
team structures are like at a lot of companies- or what the experience level
is of the average HN reader. Because you're right, PMs don't have the insight
to understand the nuances of technical debt and the benefits and costs
associated with varied approaches, and really it's not their job to. As
technical folks, it's our job to learn how to say "no", and not just in an
abrasive way that shuts down the conversation, but to work with project
managers and decision makers, understand the reasons for their decisions, and
push back firmly but using language that they can relate to and speaking to
their problems.

Regardless of how much PMs might want things or fiddle with the schedule, as
professionals it's our job- not theirs- to say when things can't be done,
shouldn't be attempted, or might cost more than they're worth.

~~~
notabee
And then after saying no, you can watch the executives hire or promote up
someone who says what they want to hear regardless of its feasibility, usually
while using the latest buzzwords. Lacking domain knowledge or the interest to
acquire it is a good sign that they will lack the awareness to avoid facile
answers.

~~~
eanzenberg
Saying "No" or shutting that door down is a bad thing that I don't like
either. Rephrase it by using "sure, we could build that, however it will
require X person-days with a team of Y senior level engineers."

~~~
s73v3r_
Don't do that. All they're going to hear is "Sure, we could do that." They're
not going to listen to the rest of it, and then it's going to be your fault
when stuff doesn't work.

~~~
Thrymr
Another way to say it is "We could do that, but it will delay this other thing
that is on your roadmap as top priority for X months."

~~~
s73v3r_
The second they hear "We could do that," they tune the rest of everything out.

~~~
NegativeK
I've interacted with some bad sales people before, but they rarely tune out
when you say things are going to be delayed.

------
nautilus12
I'm starting to see a trend in hacker news stories of the type:

Why _bad for you thing_ is actually good for you. or Why _thing everybody
likes_ is not so great after all.

Is everyone on hacker news just a compulsive contrarian?

~~~
spaceribs
Having a community that challenges assumptions is why I come here.

~~~
reificator
Even going back to my teen years I've always tried to avoid ending up in a
bubble of agreement. It's become even more important of a skill in the age of
the internet.

Whenever I'm told that I'm not allowed to disagree for some reason or another,
I immediately stop and reevaluate my views. Usually they don't change, but
it's worth it for the times that they do.

And often times when I've changed my views like that, there's a cultural shift
a little while later. A lot of what is held as sacred truth is due to fear of
the "opposing idea" being right.

Think about programming in the late 90s and early 2000s, but not believing OO
to be a panacea. I use OO when it's appropriate, but it's often not. And
speaking up about that in those times meant you were viewed as ignorant.

If you program in Java in the year 2000, you have a vested interest in OO
adoption. You've invested your time in a language that was explicitly designed
to not allow for anything but OO. And if OO is not the end-all be-all of
programming, then maybe you've wasted your time. So anyone claiming otherwise
is indirectly threatening your livelihood. You're terrified that they might be
right, so you insist that they never could be.

------
allyjweir
From my recent experience in a new team, this article strikes a chord.

Joining a team that is scared of technical debt and runs circles round
themselves in a bid to avoid it end up producing more debt than they would
otherwise. For example, making code overly DRY and wrong abstractions coupling
unrelated parts of the system unnecessarily.

We must embrace the reality of technical debt. It is unavoidable and not
something to be scared of. It can be managed by keeping things simple, clearly
tested and keeping a cool head.

~~~
spdionis
> making code overly DRY and wrong abstractions coupling unrelated parts of
> the system unnecessarily

I would say that's just bad engineering due to lack of insight or experience.
DRY is the most simple and most dangerous principle (or "best-practice") of
them all, because when it goes wrong it's the one that hurts the most.

~~~
allyjweir
Yes I agree. Bad engineering led them to not accepting the reality that
technical debt is unavoidable. In a misguided attempt to avoid it, they
overengineered ironically leading to more debt than might otherwise have
accrued.

------
skrebbel
I'd say that technical debt is often the best kind of debt you can take on as
a startup. Difficult to maintain code is _not_ going to be the thing that puts
you out of business. Usually that's making the wrong product or not being able
to reach your market.

Compare that to the other kinds of debt (convertible, for instance). They cost
a lot of time to obtain and, potentially, a lot of money in the long run if
you do well.

Many of the most successful startups had (have?) shitty code. Of course
there's great counterexamples (i.e. WhatsApp having a 5 person backend team
when they were acquired), but as a programmer and founder I find that my urge
to make shitty code and ship fast is waay smaller than my urge to make
fantastic beautiful code.

Of course shipping fast does not imply writing crap code in general. _At all_.
But sometimes it does, and when it does, I've learned that hard way that maybe
it's better to choose the crap code.

~~~
marcosdumay
How often being unable to change your code is the cause of bad product-market
fit?

How does needing 40 people instead of 5 to run your infrastructure compares
with the carry cost of monetary debt?

If you were only arguing that the people around here probably needs to be more
open to technical debt because we here are mostly perfectionists I would
probably agree. But I don't think I can agree with most of what is your post.

~~~
skrebbel
By the time we can afford to pay 5(!), let alone 40 people to run our
infrastructure, I don't think you can call us a startup anymore.

This is my point exactly. Until you've found product market fit, the size of
the infrastructure team "once you're big" should be the least of your
concerns.

Personally I don't understand how any tech company with a 5+ person
infrastructure team can still be called a startup (unless the infrastructure
is the product ofc, eg if you're a PaaS or something)

------
j45
Technical debt can benefit from being managed in it's own category - it's
inevitable as bugs and features. Unmanaged technical debt is sometimes the
'bad' technical debt we think and read about in hindsight.

When I'm a little more aware of technical debt being created - I track and
manage it just like a feature or a bug in the project management system.
Separate type, label or category of ticket. It surprising several tools don't
have this out of the box for some reason.

There's a few benefits to technical Debt being categorized separately:

Tracking technical debt helps provide a sense of the technical debt tickets
that are being opened, and floating around both in numbers, size and unknowns.

Keeping technical debt items tracked along side features, and bugs in it's own
category is an invaluable form of cross-training to new team members who are
learning the why the current code base came to be how it is, and not just what
they may see or think is best.

We see how good we might be as a team and individually at identifying
technical debt, and if we are improving at identifying it, and help develop a
ratio for future accuracy.

Regular technical debt review helps create a sense of what technical debt is
occurring, and what can be fixed under the hood on another project, if
desired, or possible.

Keeping an eye on technical debt is important too, if something initially
small is at risk of painting the project into a corner, or becoming
exponentially difficult to re-factor.

Would love to hear strategies and tactics you might use in your TD practice.

~~~
convolvatron
even if its not timely to implement - design the replacement right away, and
update it if necessary. this helps scope the work, understand what other
components are being effected, and allows related systems to be written with
an eye towards the fixed version instead of the damaged one.

~~~
j45
That's a really good idea.

We make the technical debt ticket anyways describing the problem, taking a few
more minutes to describe "how it should be" so a design process can begin...
it will be much easier to pick it up later on... maybe even tie it to an
ongoing Technical Debt Roadmap that can be tied into the main product roadmap.

~~~
convolvatron
i forgot the most important part, this helps makes the decision of when to
actually commit to making the change. instead of setting aside bandwidth to
address debt just on principle, you can make a reasoned argument that says
'new feature y would fall out naturally if we reworked x, and is going to be a
disaster if we don't, so maybe we probably should'

------
gowld
"Bad code isn’t Technical Debt, it’s an unhedged Call Option"

[http://www.ontechnicaldebt.com/blog/bad-code-isnt-
technical-...](http://www.ontechnicaldebt.com/blog/bad-code-isnt-technical-
debt-its-an-unhedged-call-option/)

------
arethuza
I've often thought that what software projects need is some equivalent of a
balance sheet and P&L report - "assets" and "liabilities" together with
"income" and "expenditure" equivalents.

Looking at technical debt in isolation and always regarding it as a bad thing
always seemed simplistic to me.

~~~
humanrebar
Agreed. I've seen teams use no metrics. And I've seen teams use one or two
metrics. I haven't seen management deal with complexity like a professional
analyst for a pro sports club would: with a range of different metrics to
inform human judgements.

~~~
noxToken
How do you measure complexity with an objective number? I have a few ideas for
what could go into it for a given task or process (number of branching paths,
number of methods called, LOC, time to develop, etc.) but how do you assign
weights to these?

~~~
humanrebar
> ...how do you assign weights to [metrics]

To start with, you don't. Baseball managers and scouts look at a lot of
metrics: runs, hits, walks, OBP, VAR, number of pitches in a career, convicted
felonies, etc. But at the end of the day, there are people making judgement
calls. They're just, ideally, exceptionally well-informed people.

So what I'd like to see, at least initially, is a healthier universe of
metrics we can automatically grab from code bases. Deciders can set up
dashboards or reports for those as needed. There would still be actual
conversations and decisions involving actual humans, but they'd be looking at
this data as they're having qualitative discussions about their options.

------
davidhyde
"If there's a chance that the code you're writing will never be touched again,
why bother to invest a lot of time in it?" In that case, leave some Technical
Debt at the end and allow the next requirement to drive a better design."

------
monksy
This is one of those things I don't understand about about software
engineering and developers lacking professionalism.

Articles and handwavy comments tend to dismiss technical debt as a shrivelling
pesky geek who keeps waxing on about how vi is better than emacs. (Someone who
doesn't have a lot of influence, nor as important).

Pushing techincal debt to be managed by the PO, Scrummaster, busuiness, and/or
managers creates major concerns and problems with what you're producing. The
passive agressive response: "well convince them" is naive and wrong. They
don't care. If we've seen anything from the experiences below, they just end
up hoping those days won't come.

Examples:

1\. Experian- I'm fairly confident that they had at last one engineer there
that bitched about how much the dependencies were falling behind. If they have
good ones, there would have been talk about how to automate that process.

2\. Half baked products/data loss bugs - (See mongo)

3\. Frequent "redesigns of projects" \- There are major companies out there
that have had to redo their entire product range due to this. It can't
possibly be affordable. I'm sure theres lot's of lessions on the migrations.
But it's a lot more expensive in the long run. Side rant: I guess if you
believe that you're going to go out of business tomorrw, this is justified.

My point:

1\. Be a professional developer, get deep knowledge on frameworks

2\. Take your time and develop correctly at the start

3\. Build experience with engineering, not the latest JS library that ignores
experience.

4\. Actually give a shit. Venkat Subermanian made a great qoute at one time:
Your code quality is a reflection about how you feel about yourself and your
coworkers.

~~~
hinkley
Some people want to appear to by high minded as long as it doesn’t
inconvenience them.

Scapegoating the business is the easiest thing to do. But when push comes to
shove they just don’t want to put in the work.

------
ericmcer
Programmer morale is another factor in good/bad technical debt. It can be
quite enjoyable to take something like three separate implementations of a
similar function, combine them, and delete a bunch of duplicate code.

On the other hand, it is nightmarish to toil through some tightly coupled mess
and try to rewrite it in a manner that is more maintainable.

One makes you feel happy and in control, the other makes you feel like
everything is falling apart.

~~~
bcbrown
> it is nightmarish to toil through some tightly coupled mess and try to
> rewrite it in a manner that is more maintainable.

I'm doing that right now, and it's great. There's several responsibilities
that are all tightly coupled, and I'm pulling them into multiple components.
It's requiring a lot of code archeology and reverse engineering of intent, but
it's incredibly satisfying at the end.

------
mikekchar
I'd like to quibble a bit with the definition of technical debt being used. A
decision not to refactor code when you don't know if you will be improving it
is not technical debt in my book. There are many times when I look at a piece
of code and say, "This is a smell here, but until we know better what we are
building I can't remove the smell". It actually _would_ be technical debt if I
covered up the smell with something pretty that wasn't related to what I
actually needed. Later on I'll have to remove that pretty code (or work around
it). Hopefully making me feel better about apparent lack of smells is worth it
;-)

The idea of technical debt is that you are trading some kind of
completeness/correctness in the code for something else that is valuable.
Usually that valuable thing is time, but it can be something else. For
example, perhaps you know that your requirements are wrong. However, the
client is unhappy with answering questions. You _could_ pester them some more,
or you could implement the obviously wrong requirements and wait for them to
find the problem themselves. In this way you defer the frustration of your
client to a later time when they might be more approachable.

It should go without saying that you should almost never do the above: I'm
only using it as an example of tech debt that isn't to do with saving time.

There are lots of times where technical debt is beneficial. The key is to
understand the cost/benefit. This is where we usually go wrong. The
cost/benefit analysis is usually done by someone who only understands the
benefit. It's just making the analysis of borrowing money and making the
assumption that you don't have to pay it back. Hmm... how much money should I
borrow in that case? Obviously, as much as I can get!

------
candu
Information presentation nit: did anyone else find those "mental model"
diagrams really hard to parse? (Especially the first one.)

~~~
bloudermilk
Agreed, skipped over these. The rest of the content was golden.

------
snowwrestler
I think this is just another way of saying "avoid gold-plating." Building a
new service to stand up to millions of users and nation-state attackers is
probably overkill until you know whether anyone actually wants it.

That said, there are definitely early technical decisions that will be very
painful to change later on, like how you authenticate users and protect PII.

------
nwhatt
A lesson I learned early in my career was to avoid spinning out too much on
why a particular piece of code someone else wrote was so “bad”.

The metaphor in this article fits perfectly- the developer who wrote this
borrowed from the future, and without being there at the time, I can’t really
judge their calculations.

~~~
taneq
Also, ugly code that solves a problem for your customers is worth more (ie. is
more 'good') than pretty code which doesn't. Customers don't care what the
back-end looks like, they just want their problem solved, and pretty code
never increased revenue.

------
dayjah
I’ve always found the metaphors around Technical Debt really interesting. They
simplify it to a point where everyone “gets it”; however I have often worried
whether there’s a cult of “anti-technical-debt”, much like there are the cults
of “absolutely no credit card debt / usage ever”. Sure, it works for some, but
I’ve also seen product progress completely halt over the argument of “that’s
adding to our technical debt”, surely it would be phrased better as “this is
adding to our customers experience, at the cost of our chase for purity and
technical perfection”?

As has been said a few times in this thread: there’s nuance to engineering,
and a careful trade off. I think the metaphors are weaponized to a point where
that nuance is lost in harsh memories of student-era credit card debt.

------
arca_vorago
I know most here are focused on the dev side of things, but coming from the
sysadmin side where I've had to deal with the technical debt of devs + the
entire rest of the business IT technical debt, it is anything but good.

I've seen the insides of hundred of companies, and the number one cause of
technical debt is lack of proper manpower to work ratios. Usually due to short
term thinking of IT as a janitorial cost sink instead of as an investment.

any company that can break this mold is going to be light years ahead in the
long run, because I have a secret to tell you all...

The infrastructure holding most businesses up is set to crumble at the
slightest puff o wind, whether that wind be legal, like a lawsuit or an audit,
or technical like an internal data breach...

------
davidhyde
"If there's a chance that the code you're writing will never be touched again,
why bother to invest a lot of time in it? In that case, leave some Technical
Debt at the end and allow the next requirement to drive a better design."

I found the article excellent and I like the financial debt metaphor a lot.
However, the quote above is somewhat confusing. I usually get rid of technical
debt (post task) so that a developer can read and understand the code better.
They need to do this in order to make some future unknown change. Since a
"better design" would at least involve understanding the current design then a
strongly disagree with leaving technical debt in code you do not think will be
touched again.

~~~
toss1
While it's excellent to make the code readable for the next guy, I read this
as talking about the architecture level, where reading the code will be
largely unnecessary because it is all junked for Rev.2

I did this for one SAAS company and it worked out great. Although I had been
very much a design-everything, pre-optimize excessively type of
coder/designer, for this project at a company I co-founded I went completely
the opposite direction.

With only a slight nod to the architecture I expected we'd need later, I just
coded up the first version in the easiest high-level tools we had, separating
only one module. This allowed us to get a much better handle on the actual
requirements, especially since the marketing guys of course went out and sold
some of the prototype. Fortunately the sales were small enough that we didn't
get swamped, but it gave me real data, and strongly reinforced my plan to
build a highly modular set of interacting services such that each could run on
separate hardware, which could also be scaled in hours. This very scaleable
architecture later allowed us to take business from competitors who were
(AFAICT) were stuck in a monolithic architecture.

But after the first version had served it's purpose, no one has ever read any
of the code again in the 15 yrs since. We just started on the main version and
never looked back.

So as a person who formerly would have recommended the opposite, I can
strongly recommend making a really brief Plan A prototype / first version that
you plan to throw away. Just make sure that you do _actually_ throw it away,
and soon (code that sort-of works does have a way of sticking around too
long).

~~~
davidhyde
Good point. I guess it boils down to team size. If the team size is large then
the code is more likely to be refactored in stages than rewritten. And more
people on a team usually means more code reading than writing. Also, you have
a higher turnover of people so onboarding cost is important.

Small team size means you don't have a lot of these problems.

~~~
toss1
good pint about team size.

I'd think it may not apply so much with huge teams, as if you probably need to
have a very extensive definition of the problem to justify a large team at the
outset, so doing the long-term architecture & design up-front (vs. a throw-
away version) would likely be best.

I'd hope for a situation where the initial small team built the throw-away,
ran it hard, then use that knowledge to build the big version and the big
team.

------
blauditore
There's a fine line between iterative development ("first do it, then do it
right, then do it fast") and actual technical dept caused by bad practices
(e.g. copy-and-edit instead of re-use). The former method is well-aware of
shortcomings and heading towards eliminating them eventually, so I'm not sure
if it should even be called technical debt. Actual technical debt (like real
life debt) has the problem of "interest" attached to it, so it grows
exponentially. So if you're not constantly working to reduce it, it may grow
out of hand quickly.

------
dlwdlw
There is a dangerous moral hazard where the people who take out the debt
aren't the ones to pay it back though. I've seen quite a few people jump from
company to company using roundabout ways of creating success that are actually
debt of some form. Then they leave as the success is claimed with their resume
showing that once this lynchpin left the team/company fell apart...

------
bandrami
That's a decent argument for bottom-up programming. Though I'd also say what's
really at issue here is short term vs. long term technical debt. Writing
software bottom-up front-loads some short term technical debt but leaves you
much better able to avoid long-term technical debt because you have a much
more flexible product.

------
paulie_a
Technical debt is a debt that someone else will have to pay off.

My greatest accomplishment at my current job has been deleting 45K-60K lines
of code.

Not every bit of code will be perfect for many reasons, but please be
thoughtful at least, and not just hammer out code. Someone else is going to
have to clean up your mess.

~~~
ozim
Funny thing is that technical debt is not like money debt. There is a lot of
possibilities that this debt will just be deleted, obsoleted, project
discontinued.

So it is more like survivorship bias, you only get to fix debt that is still
alive. Debt that went away and no one is ever paying it is nowhere to be seen.

~~~
PeterisP
Bankruptcy is one way to erase debt, and the most horrible debts go out that
way.

So it's like survivorship bias, where the most important technical debt (the
one that kills its project) is often not noticed.

------
Drdrdrq
There are different kinds od technical debt. One should aim to keep
abstractions simple, and to be able to refactor as quickly as possible. But
that also means that the code should be manageable. Unreadable code is never a
good thing, and will slow down development considerably.

------
bloudermilk
Fantastic article. As an engineering manager working for a lot of young
startups, I’ve found technical debt to be inevitable. The author seems to have
come to the same conclusion I have: embrace technical debt by leveraging it
conciously and tracking it carefully.

------
ksk
We hear a lot about it, but how many people have actually been successful in
avoiding technical debt? Any links to writeups/blogs/analyses?

------
coldacid
A far better title for this article, given the content, would have been "How
to Manage the Inevitable Technical Debt of your Projects".

------
skolos
Financial debt - you can see a number and make judgments if you have too much
of it or too little. How do you measure technical debt?

------
s73v3r_
Technical Debt, like actual debt, is neither a good nor bad thing. The problem
is when you have the wrong amount of it.

------
fimdomeio
Best part is the narration and how Mr. computer says a lot of "undefined" in
the middle of the text. :love

------
intrasight
My org has no system updates during the month of fiscal close, so we spend
that month addressing technical debt.

