
Technical debt as an opportunity to accumulate technical wealth - prostoalex
http://firstround.com/review/forget-technical-debt-heres-how-to-build-technical-wealth/?_hsenc=p2ANqtz--kPw8wFvKVfV1GLca96jgrr2yWHIGRoFkCjsYzB1eY_6CWIsHTOIZp_ion68LPMGyONheMaUCanW0tA7FmqK5LF1XT6A&_hsmi=32846075
======
itchyouch
Or we can not look at tech debt as debt but as a unhedged call option:

[http://higherorderlogic.com/2010/07/bad-code-isnt-
technical-...](http://higherorderlogic.com/2010/07/bad-code-isnt-technical-
debt-its-an-unhedged-call-option/)

From the article:

Call options are a better model than debt for cruddy code (without tests)
because they capture the unpredictability of what we do. If I slap in an a
feature without cleaning up then I get the benefit immediately, I collect the
premium. If I never see that code again, then I’m ahead and, in retrospect, it
would have been foolish to have spent time cleaning it up.

On the other hand, if a radical new feature comes in that I have to do, all
those quick fixes suddenly become very expensive to work with. Examples I’ve
seen are a big new client that requires a port to a different platform, or a
new regulatory requirement that needs a new report. I get equivalent problems
if there’s a failure I have to interpret and fix just before a deadline, or
the team members turn over completely and no-one remembers the tacit knowledge
that helps the code make sense. The market has moved away from where I thought
it was going to be and my option has been called.

~~~
ptype
Honestly, this seems like a stretched comparison to me. How many managers
understand options? And what is even the underlying for your call option? Why
would it be a call option and not a put option?

~~~
kafkaesq
That's precisely the point - the reason so many companies fall into the trap
of technical debt is that they not only don't understand the risks of what
they're getting into; they lack the language (and analogies) to describe the
risks.

------
kristianc
Here's a question: if you have a team and an internal culture that managed to
create a legacy code mess in as little as six months in their existing app,
how is giving them a microservices architecture and Docker to play with going
to help?

If you give that team that structure, it seems to me you're highly unlikely to
end up with beautifully bounded context and highly likely to end up with even
more of a mess than you started with.

~~~
gvb
"Corgibytes often introduces new clients to Docker, making it much easier and
faster to set up new _developer environments._ " (emphasis mine)

She isn't advocating using Docker for the target environment, she is
advocating using Docker to set up a standard _development_ environment that
allows the developers to be productive[1] in 10 minutes rather than 10 hours.

I've been in the situation where the development environment is a poorly
documented, massively multi-step steaming pile. The result is I spent a lot of
time chasing down those responsible for the steaming pile (the "rockstar" in
the department) asking them how to get the development environment working.
Typically they pull the keyboard away from me, type a bunch, and then say
"there, it works." Which it does. For a while.

Rinse and repeat for every developer. Regularly.

[1] Well, at least building the system rather than staring at mysterious very
broken error messages.

~~~
rogerdpack
Isn't "setting up your environment" pretty much a one time cost, though? In my
head at least, losing a couple days up front doesn't matter as much, it's the
time _after_ that the needs to be optimized. But maybe that's just my work
place where people tend to stay on the same team for years...

~~~
marcosdumay
Shouldn't be.

When you automate "setting up your environment", you are able to switch
between several of them, create new ones for forks or extra tests, and roll
back to debug production issues.

------
tunesmith
In my experience, diagnosing the tech-debt problem, prescribing the solution,
and implementing the solution are not really the hard parts of this - the hard
part is battling the culture that led to the problem, and wrangling that huge
gulf between "seeming consensus" and "actual consensus" that the group is
actually going to change direction by _accepting_ the diagnosis, _adopting_
the solution, and _starting_ work.

Maybe an outside consultancy makes this easier since they are sort of imbued
with a moral authority when coming in, but it could also mean that all the
hard political work has been done beforehand in agreeing to hire them.

~~~
biocomputation
I agree. Very often I see this set forth as a problem with management, but it
seems to me that other engineers are also a significant part of the problem. I
try really, really hard to never be that engineer. If someone sees defects in
something I wrote, regardless of the scope, I'm totally fine with whatever
they do to make it better, up to and including totally replacing my work.

~~~
calinet6
It's the whole system that forms the basis for the problem: management,
engineers, PMs, Designers, everyone who touches the problem space. If you want
to improve, you need to make sure each part of the system is aligned around
the same goal. Sounds hokey, but it is the reality.

That means, as well, that it's both your responsibility and others'
responsibility at the same time. Sure, you shouldn't be "that engineer," but
you should also realize the kinds of things in the system that make someone
become "that engineer," or lead them to be "that engineer" in some situations,
or on the positive end, how certain engineers avoid it altogether. Then try to
reproduce those factors and spread them.

The problem is never individual. It's never about a good coder or a bad coder
or anything like that. There are always multiple internal and external
factors.

------
Ericson2314
I can't agree with this enough idea enough. Also I just love refactoring.

Most of my side work is contributing to existing projects, but here's the
stats for 3 school projects: 20,896 lines deleted for 30,342 written. 2 of the
projects had fixed requirements from the beginning though one was a more free-
form independent study. Additionally all 3 had only one additional author and
I did a majority of the line additions and deletions.

I'm pretty sure these numbers are way untypical for this sort of work---with
fix goals and deadlines with no more than a few months per project I assume
most people delete pretty little, and basically only during debugging.

Certainly this refactor-happy approach did cause some missed deadlines early
on, and getting all the abstractions correct still means basic functionality
often doesn't come together until the last minute. But I still that the
immense technical wealth does pay off as I get _more_ productive the longer I
maintain the project---the abstractions anticipate the sort of extensions I
may later wish to add by laying a firm foundation. And the fact that the
functionality does appear last second speaks testifies to the increasing
productivity---longer hours or last minute panic doesn't explain it.

I think most managers would be horrified this approach, but if you're a real
company planning on being around indefinitely and not some startup just
hanging together or student, this method should be all the more fitting.

~~~
mempko
Refactoring is a necessary outcome of poor design choices. It is obvious that
in a perfect world with perfectly designed software, you would never refactor
right? While I applaud your continued effort at perfection, the goal should be
less refactoring not more. Not less refactoring because we don't care about
quality, but less refactoring because we get more right from the start.

~~~
Ericson2314
I agree in principle, but here's two big (and heavily opinionated) real-world
phenomena that push back:

1\. As a die-hard function programmer believe most everything out there is
designed poorly---not because everybody incompetent but because anything
working with poorly designed languages and libraries must itself necessary be
less well designed. Bad abstractions breed other bad abstractions! To write
near-ideal software usual an excise of ripping up the foundations---so a lot
of refactoring.

2\. We learn good design best by refactoring. When righting new code,
functionality and elegance are competing goals, but when refactoring elegance
can be tackled in isolation. Furthermore, refactoring is an opportunity to
prove (to oneself and others) that given abstractions indeed make code better.
Finally, it's hard to distill good design to principles beyond "don't repeat
yourself" and "make bad things impossible", but refactoring offers an
opportunity to try things and see what works.

~~~
biocomputation
It's like we're the same person.

I've found it next to impossible to get it through ( some ) people's thick
heads that refactoring is not a sign that something was done wrong the first
time around.

>> We learn good design best by refactoring.

Exactly. This is often when the true value of a design pattern becomes crystal
clear in an applied ( rather than theoretical ) sense.

~~~
Ericson2314
You mentioned C++, but do you do statically typed functional programming too?
Then we are the same person :).

~~~
biocomputation
I haven't done any statically typed functional programming. I'm interested in
some parts of functional programming, mostly as they related to replacing raw
logic with functions.

~~~
Ericson2314
Well C++ definitely rewards care and effort in a similar way. Haskell and Rust
(to get specific) are good for me cause they allow one to write much more air-
tight abstractions, raising the upper limit on what my constant refactoring
can yield. No more of that "all abstractions leak" bullshit!

------
hinkley
I find it amusing they got their inspiration from This Old House.

Between TOH and the head mechanic (also named Bob) at the bike shop I worked
at in college, I get most of my work ethic from outside of software, and it
shows. I had high hopes for the 'craft' movement in software but haven't seen
much of it materialize.

I spent a lot of my formative years watching TOH, including the 'Pay the
Piper' episode where two very nauseous homeowners found out their remodel went
2x the original budget. Part of it was scope creep, but there was always a
hefty repair because the foundation was being destroyed by a tree or erosion,
and a couple times the entire corner of the house (including corner beams) was
rotting away from water damage caused by shoddy work on an earlier repair ten
years prior.

I am forever looking for badly-sited trees and water infiltration in my code
base, and I'm always agitating to throw out bad tools, get better ones, and
learn to use them properly. Just like Bob and Bob taught me.

~~~
biztos
I think the "craft of software" is alive and well, it's just weirdly
distributed: a few shops doing it throughout, lots of shops (and pretty much
all big companies) doing it here or there: an individual coder, a small team,
etc.

There are lots of other things like that. Take writing. We all write a bunch
of emails (etc.) every day, but how many people try, out of a sense of craft
and respect for the language, to write them well?

(Oh and I'm currently having a flat from 1914 renovated, which had additional
work done in 1938 and 1958, so I definitely appreciate your analogy.)

~~~
hinkley
I also like to make references to how if you're an electrician and the
customer asks you to run a wire through a puddle or through the plumbing, you
can tell them to politely go fuck themselves because it's not up to code.

In software we have no safety regulations and so it's up to you to win that
standoff on your own, and most of us don't have the stomach for that
confrontation, so we cave and agree to really stupid stuff all the time. And
we know that even if we say no, they'll find some other developer who will say
yes.

------
edw519
I really wanted to like this post. It's well written. With passion. Using a
common metaphor (a house). And about the biggest elephant in the I.T. room
today.

But I couldn't. Because it just skated on the surface of the iceberg.

OP is right. Technical debt is a huge problem that requires significant mind
shift to address. And I can't find a single thing here that I'd disagree with.

There's a lot of academic theory and cheer leading here. And true, it's
requisite to any further discussion. But what I would love to see are specific
prescriptions:

    
    
      How do you train to avoid the sins of the past?
      How do you enhance process (peer review, QA)?
      How do you conduct post-mortems to organize the attack?
      How do you decide what to black box and what to rewrite?
      How do you prioritize shoring up the foundation and keeping the lights on?
      How do you find tools to automate the process?
      How do you make technology decisions to set the new path?
    

And probably most of all:

    
    
      How do you fix the broken data supporting all this bad code?
    

Because any treatment of code without diving deeply into the underlying data
structure is too myoptic to be of much value.

I've estimated that half of the bad legacy code I've ever encountered would
never have even been written if the data were properly structured in the first
place. This isn't a discussion of DBMS technology, but a comprehensive
treatment of how the business operates and how it's supporting data must be
structured, regardless of technology. Fix the data and the code becomes a much
more manageable problem to attack.

Of course, maybe OP just didn't get that far.

Nice article. I'd love to read the sequel, about 5 levels deeper.

~~~
andreagoulet
That's motivation for me to write the book. :)

This article was written for more of a CEO audience, which is why it's not as
technical. You might like the podcast I did on Hanselminutes. It gets into
more technical stuff than I did on First Round.
[http://hanselminutes.com/539/learning-to-love-legacy-code-
wi...](http://hanselminutes.com/539/learning-to-love-legacy-code-with-andrea-
goulet-from-corgibytes)

~~~
edw519
I look forward to that book! (Although I'm not really sure I would classify
anything I mentioned as "technical". I think it's all "CIO-discussable".)

Welcome to Hacker News, Andrea, and thanks for making such a nice contribution
on your first day. If your motivation ever ebbs, just let me know. :-)

------
unabst
Sounds like the word "debt" is being used to make their clients feel guilty,
and the word "remodeling" is being introduced to make it sound as if they're
doing something novel.

Doesn't technical debt just reflect operational priority? How is having old
code a problem if it all works? Debating priority is not the same as
automatically asserting it as a problem.

And isn't technical wealth building always an opportunity? Why must one be in
debt? But every business has a laundry list of opportunities. Technical wealth
doesn't need to be at the top always.

If the axiom is that being cutting edge is sacrosanct, then technical wealth
would always be top priority, and technical debt would be an operational
problem. But technical debt is just a function of the technical advancement in
the field. No matter what you do, you'll always end up in debt if you sit
around long enough, and decide to call what you have "debt".

If you can make what you have better with technology available today, do it.
If not, leave it. And ignore whether a technology is new or old. Just confirm
if it is proven and tested.

~~~
catnaroek
Technical debt isn't about old vs. new technology. It's about making
technically questionable decisions for the sake of reducing development time
and costs.

~~~
unabst
Right. Except that's just one of the many ways it's defined in the article.
The article is a hot mess.

Even then, from a business perspective, reducing costs can be completely
intentional and pragmatic. Meaning it can be profitable, so debt really is the
wrong word. It's closer to sacrifice, or even frugality. You could go as far
as to say it's technical efficiency, granted it does what is expected of it.

But if it breaks or starts causing problems, then you just have problems. At
which point call it whatever you like.

~~~
catnaroek
> Meaning it can be profitable, so debt really is the wrong word.

The reason why it's called debt is because you'll have to pay it later, with
interest.

~~~
unabst
Which is not how the term is being used in the article. But also "technically
questionable decisions for the sake of reducing development time and costs"
does not automatically become debt. Technically questionable decisions happen
regardless so debt can be incurred without intending to save any money, and
reducing development time and cost can be done without questionable decisions
so without incurring any debt.

The article uses Docker as an example of "remodeling" which could very well be
a technically questionable decision, because their argument for it is that it
saves a lot of money (and is not a technical argument, which is why it could
be technically questionable).

So in a sense, they're actively promoting technical debt because they're
choosing their tools based on cost. They should rename their method from
"remodeling" to "debt restructuring" or "refinancing". Of course, the
middleman always gets paid.

~~~
catnaroek
> does not automatically become debt.

It becomes technical debt. Just like financial debt costs you the interest
rate times the amount owed, technical debt costs you time and resources spent
on refactoring and cleaning up the code, rather than on activities that
directly increase revenue, say, adding new features.

One thing that makes technical debt particularly problematic is that you can
incur in it without knowing it. Unlike the case with financial debt, where
it's impossible to “accidentally” borrow money. But, just because technical
debt is hard to measure, it doesn't mean it doesn't exist.

> reducing development time and cost can be done without questionable
> decisions so without incurring any debt.

In principle, yes. In practice, the most common way to reduce development
costs, at least in the short term, is to incur in technical debt.

> They should rename their method from "remodeling" to "debt restructuring" or
> "refinancing". Of course, the middleman always gets paid.

No disagreement here.

~~~
dragonwriter
> One thing that makes technical debt particularly problematic is that you can
> incur in it without knowing it. Unlike the case with financial debt, where
> it's impossible to “accidentally” borrow money.

Debt doesn't occur only because of agreements to borrow, it can occur because
you've incurred a liability by some other means. Which, yes, _can_ occur
accidentally.

Indeed, cutting development corners arguably risks incurring technical debt
that will manifest concretely later in a process much more like cutting
physical construction corners might risk negligence liability down the road
and less like deliberate, planned debt financing vs. paying cash upfront for
construction.

~~~
catnaroek
Good point. I hadn't considered that possibility.

------
tboyd47
The thing is that most projects fail for reasons other than technical debt.
Not having clear requirements to begin with is one, and running out of money
along the way is another big one. There's not much programmers can do about
those, and burning time working on tech debt may actually hurt you on the
second one.

Rather than thinking of it like a house you have to _live_ in, I think of a
healthy codebase more like a busy police precinct. It may be a bit messy, but
that's just because there's always something more important to do than tidy
up.

~~~
ensignavenger
What you say is correct, but to add to the analogy- if the precinct is such a
mess that the officers are constantly tripping over stuff, and criminals are
going free because they are misplacing evidence, it is probably time to do
some cleaning and organizing!

~~~
tboyd47
Absolutely. But there is a baseline level of messiness that's acceptable and
that's what I'm trying to convey (unlike a house [unless you have kids]).

------
biocomputation
Interesting perspective.

With respect to technical debt reflecting organizational problems:

I've always been surprised at how much internal resistance (management and
other programmers) I've faced when trying to pay down or eliminate technical
debt, regardless of whether it was my code or other people's code. ( For the
record, I've written plenty of bad code in my day. )

In the past when I was foolish enough to try and be deferential, I was given
excuses like 'yeah, we don't want that kind of churn in version control' and
'we have to maintain compatibility' even when compatibility isn't an issue at
all. This, more than anything taught me that it's better to seek forgiveness
than permission.

Love the concept of building technical wealth. That's a great way to put it.

------
beat
I just saw a great term on a friend's Facebook today... "refracturing". That's
when you fix bugs by introducing new bugs.

~~~
organsnyder
Not appropriate for every environment, but I've heard "refucktering" used to
describe this.

~~~
rhizome
"Refuctor Your Cukes" was a thing a few years ago, I think by Gary Bernhardt,
but I can't find it now.

------
programminggeek
There will always be technical debt because of Software
Gravity([http://brianknapp.me/software-
gravity/](http://brianknapp.me/software-gravity/)) and the Katamari Damacy
Effect([http://brianknapp.me/katamari-damacy-
effect/](http://brianknapp.me/katamari-damacy-effect/)). Both drive the
natural Evolution of Software([http://devblog.procore.com/dev/evolution-of-
software-applica...](http://devblog.procore.com/dev/evolution-of-software-
applications.html))

~~~
biocomputation
Yes, and systems that one might refer to as 'disruptive' often get traction
because they don't have the same gravitational pull as the incumbent. Maybe
magnetism is a better term because feature richness often correlates with
complexity, and that can attract and repel people.

------
mooreds
It was interesting. Too bad the company profiled doesn't really value the
developers--if you look at their careers page, they pay 110k for lead devs,
and 90k for senior devs:
[http://corgibytes.com/careers/](http://corgibytes.com/careers/) . I respect
them for stating it up front and I know they are 100% remote, but those
salaries seem a bit low to me.

But that's just ad hominem. I think working code is almost never worth a
rewrite. See "Things you should never do, part 1" for an old chestnut on the
same topic:
[http://www.joelonsoftware.com/articles/fog0000000069.html](http://www.joelonsoftware.com/articles/fog0000000069.html)

------
20years
I looked at the careers page on Corgibytes out of curiosity. Their hiring
approach is very refreshing.

~~~
pc86
> _We noticed that men constantly asked for WAY more than women when applying,
> so we decided to take the salary negotiations off the table to make it
> easier for everyone._ [0]

So I'm being punished because some people don't ask for what they're worth? I
would consider applying for the senior position but it's less than I make now.
This policy means I have to either 1) take a pay cut; 2) punch above my weight
and apply for the next rung up the ladder; 3) not apply.

I get what they're trying to do but this does not seem to be a way to go about
it while continuing to get the best applicants possible.

[0] [http://corgibytes.com/careers/](http://corgibytes.com/careers/)

~~~
20years
They hire remote and those salaries are competitive outside of the Bay Area.

I do agree however that their reasoning is a little off putting.

~~~
misthop
I don't think they are competitive outside the Bay area for the roles they are
filling. <Anecdote> A year and a half ago I was looking for (and found) a
senior/lead remote position. I had four offers from such places as Ann Arbor,
Boston, Austin, and D.C. The lowest offer was 20% more than what Corgibytes
offers to Leads (plus non-trival equity).

~~~
20years
That is good to hear. I haven't been captive in over 10 years and I am located
in a smaller town so I am a little out of the loop on what senior dev salaries
are in most places. Great to hear that remote senior dev positions are
demanding that.

------
morgante
I really take issue with this chart: [http://s3.amazonaws.com/marquee-test-
akiaisur2rgicbmpehea/H4...](http://s3.amazonaws.com/marquee-test-
akiaisur2rgicbmpehea/H4y9x4gQj61G9aK4v8Kp_Screen%20Shot%202016-08-11%20at%209.16.38%20AM.png)

In what world are old text messages or Twitter posts better technical
artifacts than commit messages or tests? The latter are directly tied to the
code expression, include a clear history, and are easily discoverable when
looking for the source of an issue or the explanation.

This is so wrong that I'm wondering if I'm reading the chart incorrectly.

------
chetanahuja
_" Break monolithic apps into micro-services that are lighter weight and more
easily maintained."_

Does anyone has any actual evidence to support this blanket claim, especially
the "more easily maintained" part of the claim? My experience is quite the
opposite. More separate processes communicating over unreliable network links
there are, higher the likelihood of failures and mysterious performance
issues. More succinctly, complexity of system goes as N^2 where N is the
number of processes communicating over unreliable links (note, my use of the
word "unreliable" is very intentional here).

------
partycoder
Code is not an asset, is a liability. Code that you own you need to maintain.

There's only so much code that you can realistically own and maintain. If you
are smart, you will seek ways of owning strictly what you need, which is the
code closer to the core of your business.

If there is code that you need and is not close to the core of your business
and does not provide a competitive advantage, open source it.

The worse code always comes from lack of visibility and accountability. Open
source promotes visibility and accountability and keeps things working and
clean.

A culture of accountability and strong technical skills attracts talent and
keeps the company competitive.

------
perseusprime11
All these articles are fine and dandy but I would like to see more pragmatic
articles on how to reduce technical debt. A lot of books have been written
aroumd software patterns, service orientation, micro services, etc but none of
them really address how to minimize technical debt over the life of software.
Also not covered properly is what accounts for texhnical debt? For example, I
have fee classes that have good unit tests, interfaces, proper seperation of
concerns but performs really bad with 1000 concurrent users. So this goes back
to how do we accurately define technical debt?

------
kelvin0
This is a very good article, and I can certainly relate to the points made
about legacy code. The problem I had was to be able to quantify the fact that
productivity of the programming team was going downhill (legacy code, little
to no tests) and be able to make a case to management. I felt like the canari
in the coal mine.

Another key revelation from this article was that there are 'Makers' and
'Menders' ... At heart I think I am a maker, but sometimes need to be a mender
by necessity and this has a huge impact on my 'happiness' levels.

------
am8
"No thanks I don't want to learn more" on the spam pop-up to close it.

Of course I want to learn more. Not on this site though. Using a guilt trip
way to close a pop-up made me exit the site immediately.

------
stcredzero
This analogy works quite well. Basically, you have to look at all of the costs
of the current edifice. Maybe it costs nothing on paper to keep the ramshackle
old house the way it is, but the impression it gives to visitors is a cost.
Likewise, if you think of new hires as "visitors" was well. On the other hand,
a building that's well designed can have a positive effect on the public
perception of an organization and the mental state of the people working
within it. The same thing goes for code.

------
adrianratnapala
This slogan sounds like a platitude, but might be important.

> Stop thinking about your software as a project. Start thinking about it as a
> house you will live in for a long time.

I say it "sounds like a platitude" because experienced software engineers
already think this way instinctively. But we still call software development
jiobs _projects_ , like the building of a house rather than as an ongoing
activity.

Perhaps we should change that language.

------
gsmethells
Looks like something worth forwarding to the non-technical guy as "food for
thought".

------
Scea91
Defining legacy code as code without tests? First time I hear that.

------
camel_gopher
Not wealth - assets.

------
jMyles
Why "forget technical debt?" A better title is probably simple, "How to Build
Technical Wealth," the fact that a large part of this article is actually re-
hashing the problems of technical debt notwithstanding.

------
deedubaya
How about: "How to avoid technical debt" as a title? It seems like the
argument's main premise about building technical wealth is avoiding technical
debt....

duh?

~~~
beat
It's a marketing term. It's rebranding refactoring/cleanup as "technical
wealth", which sounds good compared to the "technical debt" companies are
tolerating.

There's nothing wrong with good marketing if it's leading to a solution for
both parties involved.

~~~
wry_discontent
Programmers are often logical people who neglect the importance of PR.
Convincing people and marketing good solutions to them for reasons they don't
necessarily understand is a powerful tool.

------
vegabook
_> Technical debt always reflects an operations problem_

This is a clueless statement. Technical debt is just like any other debt. It's
about getting product out fast during a phase where market-share build is
crucial, building a dominant position, and then repaying the debt from the
much larger resultant revenues, later. This is a critical aspect of the
microeconomics of any business relying on network effects. You have to be good
(enough), but really you have to be first (ish), and technical debt helps you
be first.

Therefore, technical debt, just like financial debt, is absolutely not an
operations problem. That's why we have COOs and CFOs whose roles are mainly
orthogonal. It's fundamentally a question of strategy of the business.

~~~
tunesmith
This is easily acceptable as true but practically it seems so easy to abuse
since there isn't any real data or standard underneath it in terms of when it
starts to make sense to pay off.

No one really knows from the outset what level of techdebt is necessary to
succeed, and if the techdebt appears costless (since, unlike the metaphor of
paying off financial debt, the interest payments feel relatively invisible),
you're always going to have people counseling risk and that it's better
strategy to move forward as "fast as possible" right up until your younger
faster competitors pass you by.

I don't have clear ideas either on when it's a good idea to pay off techdebt,
to me it generally seems to be a good idea to aim on "as soon as humanly
possible".

If people get too aggressive on solving tech debt then it turns into gold
plating - creating tech that anticipates too much and then gets discarded when
anticipations prove false. This is relatively easy to recognize when it
happens and is a good indication that you're going too far. Up until that
point, though...

~~~
vegabook
I disagree that the interest costs of technical debt feel invisible. I
personally feel a very heavy burden when cutting technical corners / coding to
specifics rather than the elegant generic cases. Indeed I spend a large amount
of time in meetings persuading non-tech people of the impact of their (often
technical-debt unaware) instincts. If you are in an organisation which is
unable to measure, even in broad terms, the impact of technical debt, then
that organisation is probably not run by the kind of people who should be
managing a tech business. It's why most successful startups in the past 10
years have been run by people who understand code.

~~~
tunesmith
Yeah, I totally agree with you when we're making the distinction between tech
and nontech people judging the techdebt.

