
Technical Debt is Not a Bad Thing - thinkingserious
http://sendgrid.com/blog/technical-debt-bad-thing/
======
michaelt
As far as I can tell, this article is saying "if you define technical debt as
something that isn't too bad, technical debt isn't too bad".

The article draws a distinction between bad code and technical debt - that
things that make it hard to refactor a system are not 'technical debt' but
'bad code'. It's my experience that being unable to refactor systems is a
consequence of accumulated technical debt - that as the interest compounds,
bad designs build on top of bad designs and you can't fix the first bad design
because the second bad design relies on it.

And the more expensive it gets to pay down the technical debt, the less anyone
wants to pay to do it.

~~~
taeric
This does seem to be an odd distinction. Though, I think the metaphor of
technical debt does support the interpretation. At least to a degree.

Technical debt should be viewed the same as any debt. With a major caveat
being that there is no time limit on it. And to that end, you don't always
have to pay down your debt.

The problem, I think, is everyone applies personal financing to thinking of
technical debt. Very rarely can an individual accrue debt that will allow them
to make money. It is not at all uncommon to make a design trade off that "pays
dividends" pretty much immediately.

And, not too shockingly, xkcd has a good visualization on this.
[http://xkcd.com/1205/](http://xkcd.com/1205/) (Granted, I can see how this is
not necessarily the same thing. But I often feel that what folks call
"technical debt" is really, "I wanted a jet liner solution for what a walk
down the street could have accomplished.")

~~~
joe_the_user
But is technical debt really like ordinary debt? I think an argument could be
made that technical debt is inherently worse than ordinary debt.

I think it relates the discussion of why software is an especially hard thing
to write.

A simple way to put it is, "planning a large system is harder than you think
it, for any value of 'you'". With another large part being that no only is
calculating the time spent on the project hard, calculating how long or short
the project will be is hard. And "harder than you think" means that no matter
how sophisticated one gets, bad estimates will tend to seduce you based on the
deadly combination of ignorance and wishful thinking - everyone experiences
wishful thinking and everyone is ignorant of the real implications of a large
enough new system.

Now, technical debt involves getting some momentary gain in the present based
on _planning_ to take of the problem in the future. And by that token,
technical debt will expose you to the risks of planning a larger system
immediately.

And this isn't to argue that one can or should eliminate technical debt - just
that there's every reason to be more wary of it than ordinary debt.

~~~
taeric
If you are challenging that technical debt is not like ordinary debt, then you
are just challenging the metaphor entirely. I agree with challenging it;
though, I think it is more applicable than you are allowing.

My personal take, is the debt is actually taken out against the knowledge of
others. That is, in technology, knowledge is the currency. To take on
technical debt, then, is to leverage other peoples knowledge.

This sounds dangerously close to my saying technical debt is the opposite of
NIH. And to an extent, I think I am. Pretty much, identify the areas where
you/your company will take full ownership of the technology versus the areas
where you will rely on the solutions of others.

I think the metaphor can be seen as double edged in this regard. Companies
such as Google can afford to make massive investments in custom build
workflows/etc. Smaller companies can not afford these investments and instead
must work with standard "off the shelf" ones.

That is, your company may not be able to afford avoiding some technical debt.
And the vast majority of the "debt" you take out will never need to be paid
back.

~~~
joe_the_user
Well,

Many metaphors can be partial metaphors and still be useful.

I agree with your point that the ordinary debt that enterprise takes hinges on
asymmetric knowledge - I think contemporary economics sometimes looks at it
that way.

Consider there are different kinds of debt. Gambling addicts will frequently
barrow money to gamble more. They get a certain high from gambling and they
have a delusional idea of their odds of winning. I think the worse sort of
software technical debt can equate to this - the planners merely have a
delusion that they have a better idea of the risks and rewards involved than
other people.

I agree that most companies have to take on technical debt. I think they do
pay for it in the form of miserable programming environments, bad software and
canceled projects. It is true that once a project is canceled, the technical
debt is gone and unpaid. But most of the world's bad debt isn't actually paid
- unless the Mafia decides you should sleep with da fishes...

~~~
taeric
I didn't mean the debt would go unpaid by the project being abandoned. I meant
more that you take on debt in every choice you make, and many of these "debts"
will not come due for anyone.

Consider, many folks that are writing PHP level apps do not know how the full
HTTP stack works. Expand that, most people writing web apps of any flavor have
a small understanding of this.

For most of us, this is not a big deal and never becomes due. We took on some
technical debt by trusting the frameworks that we have chosen to handle them
for us.

However, if any of us find ourselves at the scale of Facebook, Twitter, etc,
then we find that suddenly a lot of the tiny details of HTTP start to matter.
To the point that solutions that minimize resources and the like suddenly
matter. Heavily.

All too often, however, people use this argument in favor of "shiney new
framework." Taking on struts was technical debt because you offloaded much of
your core to them. I question whether many companies truly needed to ditch
fully working struts implementations in favor of "new shiney," though.

And then, this metaphor can be extended in amusing ways. There was the
assertion that git took on unnecessary "technical debt" by remaining in C
instead of C++. Instead, it can also be seen more as they took on the cost of
not having abstractions unto themselves.

So, my assertion is that for most projects, the benefit of a technical debt
never outweighs the downside. Not because the project will "go away" but
because it just is never really a problem.

Your gambling example is amusing to me. Few people will ever consider that
healthy debt. It is one thing to have a sponsor, and another to have an
addiction.

~~~
joe_the_user
Well,

My experience is in medium-sized-institutions rather than giant soft-centric
firm like Facebook or Google or the single-web-app startup. I think this is
where the majority of programmers still work.

Here, projects "always" last longer than you think and effects of shortcuts
accumulate in an unfortunate fashion.

You can say technical here is a "good choice" when it happens to be an
unavoidable choice. But when it is an avoidable choice, I see it as "always" a
bad choice.

\-- And my quoted "always", I mean "often and more often than it is your naive
impulse to think so that it's better to say always than to just guesstimate
that it might not happen in this case 'cause you'll be swayed by wishful
thinking"

~~~
taeric
But, here is the thing, technical debt also includes adopting "new shiny."
I've known people that decided to roll their own framework instead of just
sucking it up and using wordpress or ext. Meanwhile, someone else came along
and used these, got a solution together, and managed to knock it out of the
park.

That is, debt should be considered in this regard the same as a loan for
money. Taking out a loan to get something done quickly and with little effort
has a huge benefit. So does picking a framework that you can hire a lot of
folks for.

Further, and this can be subtle, if you are going to do this, then you bloody
use the money/technology according to the terms of the entity lending. How
many people hate maven because they decided that its way just wasn't good and
wanted to tweak it? How many people, on immediately taking up a new
technology, look for how they want to do it first? Before they have even
understood how that technology was made to be used?

This is not to say there may not be reasons to leave or tweak a technology.
But, realize for most companies it is not a viable proposition to do so.
Instead, accept and leverage the disadvantages and limitations of the
technological "debts" you have taken out.

------
j_baker
Technical debt isn't _necessarily_ bad. However, people who take joy in
pointing this out usually aren't the ones who end up paying it down every day.
It's usually a (sometimes wannabe) pointy-haired boss who's just trying to
crack the whip harder. The key is realizing that technical debt must be paid
at some point. Saying "technical debt isn't bad!" is oftentimes an excuse to
avoid paying it down.

~~~
im3w1l
Is it considered better practice to pay the debt down little by little, or all
at once (as in rewrite or feature freeze)?

~~~
ollysb
There aren't many managers around that are going to feature freeze to pay off
technical debt. In reality it has to be paid off as you come across it i.e.
you're working on a new feature that depends on some code with technical debt.
This seems fine as after all, there's not much point paying off technical debt
if it isn't slowing down development.

------
lutorm
Sure debt isn't a bad thing ... if you invest your loan wisely, and pay it
back. And "bad code" is absolutely technical debt. If it was cranked out
because of a deadline, it might be well-invested debt, if it was done because
of laziness or incompetence, then it's just like maxing out your credit card
on a trip to Vegas... but either way, the loan will come due.

------
_kulte
This title is intentionally misleading, but I'm glad for it because it was a
good read. But essentially what it is doing is redefining the term 'technical
debt' in terms of its original, intended definition, as opposed to the
definition by which it has been re-appropriated, i.e. 'bad software'.

If you define 'technical debt' in the re-appropriated sense, it is surprising
to see an article title which translates to 'Bad Software is Not a Bad Thing',
which is why I immediately read the article. But the original definition makes
so much more sense, and actually provides the motivation for thinking of
'technical debt' as having a real place in the philosophical conversation of
building software.

------
spullara
Technical debt is like debt, if you are borrowing it to expedite something and
you actually pay it down later when you have the resources it can be a good
thing. Sometimes though, it is just poor development practices or design. Here
is a presentation I gave at the FirstRound Capital CTO conference a while ago,
it was pretty well received and fun to talk about things people have seen in
their own companies:

[http://www.slideshare.net/spullara/managing-technical-
debt-1...](http://www.slideshare.net/spullara/managing-technical-
debt-15539856)

------
jasey
Technical debt comes down to the ideology of "make it work, then make it
right".

Every time I make a technical decision, I ask myself how much debt am I taking
on if I skip the "make it right" part. And what am I gaining from skipping
that step?

I think the CEO's, CTO's, product managers, mid managers and lead devs all
know they are taking on debt (if it has been communicated to them properly),
they simply make what looks like the best decision at the time as far as the
business goals are concerned.

\- The debt can be hidden until, its to late. How many times have you thought,
this code is duck tapped from top to bottom and on release its fine? On the
other hand how many times do you think code is bullet proof only for it to
fail once it hits real world use cases?

Technical debt is a risk vs reward equilibrium and everyone uses their best
judgement to decide how much they want to borrow (unless they are ignorant to
the the fact that they are taking on debt).

As the author mentions, in the context of a startup taking on technical debt.
Its much less risky.

On one side of the equilibrium we have, "build a polished product that no one
wants" then on the other side we have "release a buggy MVP, that will drive
early adopters away forever".

I would rather save time and get a MVP out ASAP, after that deciding if its
beneficial to pay off the MVP debt or to keep iterating faster and release a
2.0.

------
carsongross
A lot of what is called "technical debt" is really developers coming in after
the fact, looking at messy, real world code with years of feature build-up and
bug fixes in it, and deciding "Ugly, rewrite."

~~~
j_baker
A lot of "technical debt" is also messy, real world code that its writers
can't accept as being bad because they've dealt with it for so long and can't
think about it any other way.

~~~
Hannan
I imagine the intersection of those two sets is much larger than either camp
is likely to admit.

------
memracom
I've never understood why people do not track technical debt in the same way
that we track bugs and other issues. At least that way you can report to
management the increase in debt, and the ratio between the amount of debt and
the time to fix bugs.

------
collyw
The article heading and conclusion line seem to contradict each other.

"Technical Debt is Not a Bad Thing"

"When you don’t pay down technical debt, just like real debt, it becomes a big
problem, as I explained in Dirty Socks and Technical Debt."

------
gtirloni
Surely something HN likes to discuss.

[http://hn.algolia.com/#!/story/forever/0/technical%20debt](http://hn.algolia.com/#!/story/forever/0/technical%20debt)

------
Fasebook
correct, technical debt is a _very_ bad thing.

~~~
McUsr
My two cents is to point to an analogy with the economies of under developed
countries: The more debt you have, the more difficult it is to get rid of it,
and in the end it may lead to defaulting and bankruptcy.

So, you can't just "borrow" everywhere, and think that you are able to repay.
It is important to refactor and downpay immediately, when you realize that you
are going to depended on the debt elsewhere, or you'll get accummulated debt
when you'll have to downpay the dependencies as well.

I'll coin that as the "future value of money syndrome". :)

