
Is “Investing in improving structure” better than “Paying off technical debt”? - BerislavLopac
https://twitter.com/KentBeck/status/1187766114706542593
======
Fr0styMatt88
The whole technical debt discussion often makes me wonder if there's a
fundamental distrust (or even disrespect) of software engineers as domain
experts.

Do people in other professions have the same issues? If the salespeople say
this thing must be done in this particular way, or if the lawyers say this
thing must be done in this particular way, are they questioned and overridden
by their managers? I honestly don't know; it feels like software engineers are
given a special level of distrust but it just might be that I'm perceiving
that because I haven't experienced the other jobs.

FWIW where I currently work, we have an amazing middle-manager / product owner
who has to fight the same battles with upper management with regards to
process improvement and technical debt. She gets it, but has to fight the same
battles we do. Sales and C-level want everything now with as little investment
as possible.... I wonder if I just answered my own question?

~~~
mobjack
I distrust my fellow software engineers when they say they need time to pay
tech debt.

There were many times where I refactored code that never received any
additional updates or to have the feature removed. I wasted a lot of time
without any real gain for it.

There are real costs to paying off tech debt and it is easy for engineers to
spend their time on low value refactoring.

Software engineers are not always good at prioritizing the business value side
of their work so they aren't trusted there.

If you can show you can prioritize business value then it is easier to
convince management to give you two weeks to clean up tech debt.

~~~
stouset
> There were many times where I refactored code that never received any
> additional updates or to have the feature removed.

Since we're throwing out anecdotes, I've lost count of the number of companies
I've seen that were essentially zombies due to technical debt. They had aging,
rotting codebases that were impossible to add features to at the rate needed
to continue making sales. No senior engineers who could improve the situation
wanted to set their careers back by working for them.

~~~
pytester
Management's solution is often to hire more software engineers.

Ironically in big corporations I think that this actually plays into their
underlying desires - giving a boost to headcount gives them more importance
and having more developers means that the leverage each engineer has is
commensurately less.

I've worked on more than a few projects which would have proceeded 4x faster
with 2 good developers on a clean code base than the 7 they actually had.

Indeed the entire software startup industry is probably reliant upon this
dynamic.

~~~
pm90
Not the software startup industry, unless you're flush in easy VC cash. Most
of the startups which are trying to solve real problems that I've
known/interviewed for are extremely conservative with hiring, for the very
good reason that bad hires are not just a 0 value add, then can be a negative
value add.

Uber is one of the outliers in this regard. But if you look at most successful
others (Instagram, Whatsapp and a bunch of others I don't want to name since I
want to stay anonymous) all had very small teams right until they were
acquired.

~~~
pytester
I meant that the startup industry would be hollowed out if large corps didn't
exhibit this dysfunction and thus create space in the market for them, not
that startups do it themselves (although occasionally they do too).

~~~
pm90
Ah, that does makes sense. Apologies for misunderstanding.

------
simonw
I love the metaphor of technical debt - you take it on with your eyes open,
and sometimes you chose to pay it down.

But... in larger engineering organizations I've found that "paying off
technical debt" isn't actually a particularly useful goal - because teams can
use it as an excuse to work on pretty much anything!

If a team spends three months rewriting some code into a different style that
they prefer, is that a useful pay down of debt?

So - I prefer more targeted debt repayment. The best approach I've seen so far
is to focus on "get rid of duplicate systems". If you have two systems that
solve a particular problem and you knock that down to one, you're guaranteed
to have improved things - and it's very easy to explain to non-technical
stakeholders why having one system is better than having to maintain two.

~~~
cactus2093
> The best approach I've seen so far is to focus on "get rid of duplicate
> systems"

In my experience this still requires finding the right balance, like almost
anything else in programming. If you're too eager to get rid of duplication
you can end up combining things that aren't actually quite the same and
creating leaky abstractions that are a lot more painful than the almost-
duplication was.

There's also sometimes a trade-off involved. Maintaining two very similar
systems can be more work/require more engineers, but maintaining one system
that is used in different ways can make you more likely to introduce bugs
unexpectedly if you make a change focused on one particular use without
testing all the others enough. It might depend on the particular system which
cost is more acceptable.

~~~
simonw
Yeah I've definitely seen people refactor code to eliminate duplication in a
way that turns out to be counter-productive a few weeks later, when it turns
out the two places that use the code are evolving in different directions.

I'm thinking more about duplicate systems. A really common pattern in a
codebase that has been around for a few years is incomplete replacements:
someone builds v2 of the checkout flow, but it never quite completely reaches
feature parity with v1 for all of the edge cases so both of them stuck around.
Kill those!

~~~
Aeolun
If you refactor to avoid duplication, refactor into an interface.

------
leoc
Reposting my old comment:
[https://news.ycombinator.com/item?id=7951964](https://news.ycombinator.com/item?id=7951964)

> I don't see why the analogy to debt is necessary when the direct analogy is
> to capital underinvestment: in fact what we're talking about is or very
> nearly is just that, capital underinvestment, not simply something analogous
> to it. And the hypothetical businessy, non-technical types whom the debt
> analogy is intended to enlighten understand very clearly what deferring
> capital investment is and what the likely consequences are, at least if they
> actually know anything much about business.

msandford's reply
[https://news.ycombinator.com/item?id=7951978](https://news.ycombinator.com/item?id=7951978)
was good:

> Most of the people who are pushing for "features now, someone else's problem
> later" are probably not upper management but rather middle management. Upper
> management might understand capital underinvestment. Capital underinvestment
> is very nearly the sole job middle management is there for. And berating
> people for not being done yet. At least at a couple of the places I've
> worked.

~~~
peteretep
> when the direct analogy is to capital underinvestment

[https://www.google.co.uk/search?hl=en&gl=en&q="capital+under...](https://www.google.co.uk/search?hl=en&gl=en&q="capital+underinvestment"+-"human+capital")
(479 results)

That's because you've just made the term up. If you meant instead "the
underinvestment problem", then that's actually the opposite -- that's
avoidance of pursuing new features because it'll incur technical debt.

------
lostdog
Coming up with better terms for "tech debt" seems like a good exercise. Here
are some:

Improving the flexibility of our code base.

Investing in future execution speed.

Performing final cleanup tasks on the previous round of features.

Also, when a report comes and asks for time for "refactoring," I ask them what
they want to improve. Having a particular goal or target area for the refactor
makes it more successful, and has the side benefit of making it easier to
communicate the benefits to the rest of the company.

~~~
NullPrefix
>Performing final cleanup tasks on the previous round of features.

This implies that the previous round is not actually finished

~~~
TeMPOraL
As it should, honestly. What's really happening is that, usually due to
deadlines, a job is left unfinished, and the undone tasks (like cleanup,
optimization) are then labeled as "debt" just in order to push a ticket do
"Done" earlier.

------
tyingq
I have noticed that business folks roll their eyes when "tech debt" comes up.
I sympathize, as it didn't used to be that way. COBOL on a mainframe would
remain current for decades. Tools and languages are very fragmented these
days. I recently tried to get a popular node.js app (tech radar) up and
running, but npm just kept bombing out on abandoned packages. The project is 2
years old and already "debt ridden".

Funny, because it's all client side/ browser JavaScript. Node isn't really
needed, but that's the toolchain. So it's borked for no good reason.

~~~
BurningFrog
In general I don't think tech debt _should_ be communicated to the business
people.

It's an internal part of engineering work, and doesn't impact users. You can
think of this as "encapsulation" if you like.

Also what it sounds like to outsiders is "we're taking time off to fix things
we didn't bother to do right in the first place". And that's not *100%
wrong...

~~~
massung
> I don't think tech debt should be communicated to the business people.

This is wrong. Technical debt is almost always incurred because of the
business requirements. They need to be made aware the debt is being incurred
at that time so they are aware it will need to be paid down ASAP.

Example: a startup is asked by an investor for a particular feature to be
implemented for a trade show a week from now. That feature - if done properly
- would require a database schema change otherwise the queries will be
abysmally slow. Luckily, for the trade show the amount of data being queried
is small enough that it won't matter. But as soon as it starts getting used,
whoa boy.

Management needs to be made aware that there is technical debt being incurred
here. Yes, the deadline will be met and the show will go well. But there
better be time on the schedule to do it right afterwards.

~~~
pytester
>This is wrong. Technical debt is almost always incurred because of the
business requirements. They need to be made aware the debt is being incurred
at that time so they are aware it will need to be paid down ASAP.

I absolutely loathe doing this - the costs of technical debt are too specific
(e.g. 2 hours a week) while the benefits are too diffuse and too hard to
measure. If you have a conversation with business people about it it feels
like you're having to make a business case for buying pencils.

~~~
Thorrez
> benefits are too diffuse and too hard to measure.

Wouldn't "the feature gets done in 1 day instead of 2 weeks" be a very
specific benefit?

~~~
pytester
It would be, but the most realistic, specifc claim you could typically make is
that some hypothetical feature that probably hasn't even been dreamed up yet
would get done in less time than it normally would.

It's a hard sell, and that's precisely why it doesn't get done.

~~~
Thorrez
Maybe I'm misunderstanding. I think "the benefits [of technical debt]" are the
reasons for taking on technical debt. When you take on technical debt it's for
a specific feature that's needed, not for something that hasn't been dreamed
up yet.

------
al2o3cr
Disagree - "investing" is an activity that can be deferred without anything
but opportunity cost; "paying off debt" expresses that _not_ doing it has real
consequences.

~~~
TeMPOraL
I sort of agree with the author, for a similar reason that I don't like the
concept of code rotting. Digital artifacts left alone don't change. They don't
become more broken over time. Technical debt in code you're not currently
modifying isn't incurring interest - and a debt without interest is one that
you can safely leave unpaid indefinetly.

Both "code rot" and "technical debt" are concepts that, unlike their real-
world analogs, are only problematic in context of ever changing environment. I
feel this is a crucial and unmentioned difference that makes the analogy bad.

~~~
ebcode
> Both "code rot" and "technical debt" are concepts that, unlike their real-
> world analogs, are only problematic in context of ever changing environment.

It should be taken as a given that code (and everything else) exists in an
ever changing environment. Computers are physical machines; they run down over
time. Capacitors need to be replaced, and you've got to blow the dust out of
your fans once in a while.

Especially in web development, the environment changes quickly. Who could have
foreseen that the authors of the JavaScript spec would introduce their own
"remove" function? Not me: I left my code unchanged, and it broke. Or, more
technically, it _rotted_.

~~~
TeMPOraL
Let's be honest - web development is crazy land. It's an outlier, by far the
fastest moving area of our industry. And that's still only if you follow the
"best practices"

Maybe I should've put it in a different way: one of the biggest benefits of
putting things in a digital form is that the digital form is immune to decay,
as long as someone maintains the infrastructure for copying and reading that
digital data. The default state of digital data - including code - is not
rotting. We do a lot of extra work to _make_ it rot. So the question should
be, why are we doing it, and shouldn't we embrace this feature of permanence
that we get for free? It's not impossible [0][1].

Version pinning and only doing updates in explicit, planned steps, is a start.
Runtime environment can be virtualized and thus made to outlive hardware
(virtualization is a way to turn hardware into software, to make the former
immune to decay). Web folks have Babel, which today is used to evolve the
language faster than the browsers can keep up with, but it could be used for
the reverse - instead of compiling ES1234 into ES5, it could also be made to
compile ES5 into whatever backwards-incompatible ES-whatever the browsers will
be running 5 years from now. This is how you restore the pristine state of
code undecaying. The nice thing about the digital medium is that it only
requires maintenance at the boundaries of change, and we get to move those
boundaries - we could opt to keep them concentrated in few places (like
virtualization software, transpilers, hardware abstraction layers), instead of
spreading them out everywhere and then saying that the code "rots".

\--

[0] - Common Lisp has many warts that make it suboptimal for modern software
development, but one of the best things about it is that CL code doesn't rot
much. When you pull in a CL library that's 15-20 years old, you expect it to
run without changes. With 25+ years codebase, you might need _some_ fixes,
mostly because the language wasn't standardized until 1994.

[1] - Maintaining backwards compatibility matters too. I can take a Windows
.exe compiled 15 years ago and I expect it to run on a modern Windows machine
just fine. Arguably, this is one of the main reason for success of Windows -
Microsoft put in work to ensure old software doesn't break in new Windows
versions.

------
jsdalton
I have for the most part stopped using the term technical debt, especially
when talking to non engineers. There are many reasons why I believe it is an
exceptionally poor term, not the least of which being that, unlike monetary
debt, technical debt is not quantifiable. Imagine approaching your CFO and
convincing him to take out financing to fund an upcoming project, and bring
completely unable to tell him the principal amount, the interest or the terms
of repayment. I’ve certainly never seen any organization buy into the metaphor
deeply enough that they were capable of reasoning about it with anything close
to such financial permission.

The term I prefer and use quite frequently these days is “technical health.”
As in, choosing to continue to the next project without refactoring the new
features that we rushed to deliver will negative impact technical health.
Technically unhealthy code or services are slow, complex, unreliable, not
performant and cumbersome. Technically healthy services allow us to be nimble,
to make changes with ease and speed. They are easy to work with and easy to
reason about, particularly when things go wrong.

~~~
regularfry
It should be quantifiable to within an order of magnitude or so, although
possibly not in advance. In my experience the problem is that any individual
piece of technical debt is too small for it to seem to be worth the effort for
the difference knowing the value would make.

------
drewcoo
When anything except new features is called "tech debt" I think Ward
Cunningham's analogy has been stretched too far. It's supposed to mean
forgoing needed work now with the intent to do it later. People should balk at
unexpected bugs or unplanned refactoring being called that.

~~~
Forge36
Occasionally the new feature's debt is never paid. I'm cleaning up a location
which has had this happen 30+ times over 20 years. It resulted in 15+ sightly
different ways of doing the same thing. Much of this without a function call
in sight. I've been splitting functions out of it slowly reducing the 80+
variables into discrete behaviors. It's now unit testable.

I'm often asked why can't I add something quickly, pointing to this file is
more than enough reason for all but the most important projects to agree to
wait.

What should I call this if not Technical Debt?

~~~
regularfry
It is tech debt, it just wasn't taken on as a debt intentionally. It's like
going wild with a credit card - it's debt, but there was no rational thought
as to what the consequences would be or how it would be repaid.

------
eloff
They're both good. Stop trying to reduce a multivariate problem to a single
variable problem. Managing a software project, leading a team, running a
company, raising children are multivariate problems. There is no right answer
or best tradeoff in all circumstances. Everything is highly context dependent
and there's a balance. You have to walk that line and be careful not to stray
too far to either side in everything. You can be too assertive, you can not be
assertive enough. You can focus too much on technical debt, but you can also
not spend enough resources addressing it and have it cost you more in the long
run. Find the balance. Thats what leadership, and more broadly, life, is all
about.

------
PeterisP
IMHO there are parallels with "physical" engineering if you look carefully.
Here are some examples:

1) We figure out that asbestos is bad, mmkay. Now suddenly half of the
buildings have a need to perform expensive maintenance work even though their
business needs for "features" have not changed - that's analogous to finding a
security vulnerability in a subsystem or protocol that's not even your own but
that your system uses, where fixing that may take a lot of work.

2) For electric wiring. You may have a building wired properly according to
code requirements as it was in 1950. Nowadays we have a better understanding
of what's safe and not, and while you're often not required to fix that
immediately, in many places you wouldn't be allowed to "just" do minor changes
- if you do alterations, then after you're done that place must be meet the
current code requirements, which may require extensive expensive work. This
has a clear analogy to the type of technical debt caused by relying on an
obsolete version of some dependency - adding small new stuff may force you to
do integration work so that your system works with a newer version of that
dependency.

3) Another example of electric wiring - you may sometimes encounter improper
work done that way to save time or money because of some urgent deadline. And
you can't just come in and make up the missing parts later - fixing it often
requires simply ripping all of it out and putting in the wires properly; so if
it's not a temporary place that's up for demolishing soon (just as with
software, temporary structures also sometimes stay used much, much longer than
planned) then you need to re-do it eventually if you want to keep using it
safely. And there are cases just like that in software.

People handling construction and reconstruction projects, as well as all their
customers, have some understanding of these concepts when it applies to the
physical world, and it's not that surprising to them (well, the costs for the
tasks mentioned above are sometimes unpleasantly surprising) - so perhaps we
should frame it in similar terminology to piggyback off of _these_ analogies
instead of debt?

~~~
alacombe
Or the company can't source the same materials / quality as before (supplier
change, company moves, etc) and need to go into trouble fulfilling existing
orders with the old design (paying extra both time and money for the old
material) while trying to sort out a new design with the new material
available...

~~~
PeterisP
Yes, companies sometimes have to redesign their product (costing a bunch of
time and money and potentially making it worse) because they can't supply some
ingredient or technical part anymore and have to use something else... which
is pretty much the same thing as having to rework your system because a
software dependency you're using isn't supported anymore.

Furthermore, you may simply be working with a supplier where you _know_ that
they're stopping production or going out of business soon, and you _know_ that
you'll need to rework your physical product soon but haven't started doing
that yet, such cases happen, they'd show up on internal risk assessments and
shareholder reports - and I'm not certain how this class of challenges as a
whole would be called in the (non-software) business world, but it's
definitely not "debt".

------
peteretep
As anyone who's had the misfortune to be involved in commercial decisions will
know:

> Investing in [something that sounds like infrastructure]

CapEx

> Paying off technical debt

OpEx

See also:
[https://twitter.com/swiftonsecurity/status/64279083695501312...](https://twitter.com/swiftonsecurity/status/642790836955013120)

------
quickthrower2
Yes, because the debt analogy is strained:

Debt: * Interest is due on a periodic basis, with consequences if you default
such as recovery, court, reposession, bankruptcy. * You may be asked to pay
back the principal on a trigger (e.g. margin call) depending on the contract,
or you may have to pay towards it each month (repayment mortgage)

"Tech Debt": * No pressure to repay * There is arguably a recurring cost to
having bad structure, but this cost varies based on the amount of activity on
the codebase. No new features and only security bug fixes = very little
interest and no new tech debt. This is unlike regular debt. * Can't really be
measured accurately (like real debt). * If the company is sold it is not on
the books.

So it's sort of like debt, but not exactly.

------
danbmil99
In my experience, technical debt is much more about time-to-market
minimization than it is about reducing costs. Here in Silicon Valley, raising
capital is usually not the limiting factor. However, the spoils to be had by
being first to Market are so great that they justify pushing a lot of pain
into the future just to be the first to get the product out the door and get
the first-mover advantage.

I've observed that often programmers in the trenches I don't really understand
the dynamics of the business well enough to be trusted to make critical
decisions regarding these trade-offs.

------
BerislavLopac
In a way, one could argue that there is no such thing as "technical debt".

This term usually denotes technical decisions which lead to functional
software at a cost of now difficulty in future development, debugging,
performance etc. But that cost only matters only when it's actually collected,
e.g. when later development is actually difficult because of those decisions.
Which might never come to pass, and activities to"improve" the codebase are
wasted unless one is 100% certain that it will happen.

It might be better to consider that practice "fixing non-functional bugs".

------
bobbonew
I got hired as a project manager to oversee the 5 programmers on a massive
project once. Their previous “supervisor” was the owner/ceo with NO technical
background for about 14 months.

Every single feature and block of code was written in 30% the time it should
have been given. The ceo had no idea the technical debt he was creating until
it was too late.

The day I came aboard any new feature or change that could be completed in
100% standard time needed 200%+ the standard time to account for the shortcuts
taken over the previous 14 months.

It was a total shit show and a half.

The company shut down 6 months later.

~~~
fancyfish
How did you approach your role as PM, aware of the tech debt but also
reporting to an unaware CEO? Power through with new features at half the
speed, or try to convince the CEO to allow refactoring/maintenance?

~~~
bobbonew
Sorry for the delayed response (no notification on mobile).

For some reason my relationship with the ceo was viewed as trusting whereas
their programming team was not. I was able to get the time required (in 9 out
of 10 situations) by explaining in detail why it was required.

We actually had a complete rewrite in the pipeline - an architecture written
by myself - that was on the table. But they shut down before that was
possible.

I don’t regret taking the position despite the frustration and difficult
inherent to what I had to tackle. I got a very closeup view on technical debt
that has assisted me throughout my entire career.

------
joejerryronnie
Our marketing team understands the power of framing a concept in a favorable
light as they are constantly correcting our use of "eating our own dog food"
to "drinking our own champagne". Of course, I paraphrase this to "drinking our
own dog food".

~~~
goatinaboat
Eating your own dog food is a reference to
[https://en.wikipedia.org/wiki/Alpo_(pet_food)#Marketing](https://en.wikipedia.org/wiki/Alpo_\(pet_food\)#Marketing)
I’m surprised marketing guys don’t know that

~~~
detaro
One can easily know what it is a reference to and think it's bad framing.

------
altacc
I agree. It’s amazing how important a choice of words can be. The word debt
has negative connotations for many people, perhaps even hints of
irresponsibility (e.g. you should have done it properly in the first place).
It’s not always possible or efficient to educate non-technical colleagues, so
I find that using more business oriented language really helps with getting
that work accepted as meaningful. Even within the team, highlighting the
benefits of the work leads to a more positive approach (although at the
developer level we love removing terrible code, so don’t need much
motivation).

------
clumsysmurf
The problem I have with opportunistic refactoring, in the context of Scrum at
least, is usually the extent of the cleanup is not known until you start
making changes. By that time, you have already given an estimate for the story
points. Hopefully, the business considers this a forecast. Unfortunately, many
times this is considered a commitment. If you do the refactor, you may miss
your commitment, and easily measurable things for the business (your velocity)
look bad while something that was not easily measured (tech debt) remains
unquantifiable and unchanged either way.

~~~
regularfry
That version of Scrum is horrible, and should be fixed. Scrum switched
"commitment" to "forecast" in 2011, and it should be well known by now that
you can't compare velocity across teams, or even within the same team out past
a couple of sprints.

------
SideburnsOfDoom
Define "Investing in improving structure" \- Of code? of system architecture?
of teams and of company?

Define "is x better than y" \- are we talking about comparing two different
activities, or is the question about different ways to name the same subject?

Is it better because it's a more productive activity, or because "if you do y,
you'll also get x as a side-effect" ?

I'm sorry, without much clearer phrasing, the question is hopelessly ill-posed
to me. Can't answer something that could mean anything.

------
debrice
I don’t believe you can answer that question... or that this question has an
answer. I read a few assumptions that technical debt can be due to bad coding
practice. While it could be, in my experience it often comes from business
goals changing, rendering some past infrastructure obsolete or improper. There
is also a lot of value for engineers to deal with debt. If dealing with debt
is hard, it probably will make your team better.

------
thanhhaimai
I only use the term "Tech Debt" among engineering team. For communicating to a
broader audience, I use:

"Improve product, engineering, and operational excellence".

The idea is that the broader audience focus is on the overall benefits and
costs, not on whether we have debt. This phrase also allows me to make process
changes that improves the team's efficiency outside of Tech Debt.

------
toast0
You don't pay off technical debt. At best, you refinance it.

Unless you're ending features, products, or companies.

~~~
dmurray
Or dependencies.

------
jayd16
I agree more with some of the replied about calling out direct product value
instead of rebranding to another even more vague concept.

It's a lot easier to sell bug fixes, stability or performance over a vague
"debt/investment" that may or may not be noticable to stakeholders.

------
rdlecler1
That We have the ability to have technical credit to draw down on shows the
power of software and is valuable because it means you don’t necessarily need
to build robust code to get something up and functional and it gives you an
opportunity to learn.

------
cjfd
Recently I was asked to come up with a word for this kind of thing and after
some thinking I settled on 'reliability'. So now we sometimes spend a bit of
time on 'reliability' which sounds pretty nice, doesn't it?

------
philwelch
Sometimes, and it also drives better decisions that way.

If you have code that’s janky in some way but requires little maintenance or
will be outright replaced in the near future, letting it remain janky is a
reasonable decision.

------
bacon_waffle
Lately I've been talking about technical rent, for instance updating a local
fork of an external codebase, and feel like that distinction helps my group
more thoughtfully use the technical debt metaphor.

------
bboreham
In financial terms, it’s more like you sold an unhedged put option. I.e. you
may be required to pay the difference, at some point in the future, not of
your choosing.

------
massung
The problem here is the mischaracterization of what technical debt is.

Most of the time I hear programmers talk about technical debt, what they
really mean is profiling and performance (because over time requirements
change and code size increases) or code "cleanup" which is usually a catch-all
for "not how I would have done it".

Performance issues are real, but those should just be scheduled and tackled as
needed. Code cleanup is quite often a red herring.

But technical debt is entirely different. It's exactly what the name implies:
debt. We would have done X to implement a given feature or customer request,
because there are many conditions and other systems to take into account. But
there wasn't time to do it that way before the required deadline, so we did
something else instead that would get by for now, but we all know won't last.

That is technical debt.

Sadly, often times management just see the issue as done on the schedule and
there should therefore be no need to go back and "do it again".

Always pay down technical debt when you can. It will be paid eventually, it's
just a question of how painful it will be when you do.

~~~
TeMPOraL
How's that meaningfully different than performance and code cleanup cases?
Frequently, a team know how to implement a feature in an efficient manner, but
only has time for a low-performance hack job. Similarly, "code cleanup" is as
much a code word for "not how I would have done it" as it is for "bad
architecture that will start constraining us very soon".

~~~
massung
Performance work is no different than new features: requirements change.

Code cleanup can mean many things. When talking about architecture, it could
be a legit argument that due to requirement changes there needs to be a
rethink. But that's not debt. That wasn't a conscious decision made in the
past to do A instead of B knowing that B was the right choice, but not
realistic at the moment.

When talking about large code bases that have been around, code cleanup is a
young person's term that tends to imply they are smarter or know more than the
previous set of programmers who worked on it. That's possible, but a bad
argument. And it's insulting. Obviously the code has worked for quite a while
successfully, so it can't be as bad as it's being made it to be (that's
management playing devil's advocate). If it hasn't been working, the schedule
should reflect fixing it. Maybe that requires a massive recoding, but maybe
not.

~~~
closeparen
Cleanup is not about how the code works at runtime, but how well it supports
change. An abstraction that looked right at the time shows its cracks years
later. Changes that should be simple and low-risk become intense and scary
when they need to fit in with it.

It's not insulting. For one thing, the person proposing the change may very
well be the original author. For another, you have the benefit of hindsight
and access to information they didn't about what bugs would emerge, which
features would be demanded, and how hard it would be to implement them. Of
_course_ you're going to see better ways of doing things than were visible on
day 0.

Increasing speed and reducing risk for _all future iteration_ is some of the
highest impact work you can do; rather than shipping a single feature, you're
a force multiplier for all the features developed by your team.

The only time it makes sense to skip cleanup is when you're content to just
let the thing run, and don't see any changes in the pipeline.

~~~
jyounker
> Cleanup is not about how the code works at runtime, but how well it supports
> change.

This. A thousand times, this.

------
davio
I make people put money in the swear jar when they say "Tech Debt"

------
hevi_jos
Of course, if you like to lie to outsiders so they don't really don't know how
f _cked your code is, it is a better term, along with:

-calling "restructuring the debt" when you are broke

-"negative growth" when the economy goes down

-"let people go" when you fire people

-"termination of pregnancy" to tear off the head of a fetus while she is alive.

Technical debt is the necessary bad that programmers create because of live's
realities.

The only problem is that when you start telling lies to others, you could end
up believing it yourself.

Also the people you tell lies to could get fed up of your constant lies,
distrust you and consider you just a piece of cr_p,just like politicians.

