Technical Debt is Not a Bad Thing

http://sendgrid.com/blog/technical-debt-bad-thing/

by thinkingserious • 12 years ago

24 40 12 years ago

sendgrid.com

gtirloni• 12 years ago

Surely something HN likes to discuss.

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

carsongross• 12 years ago

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_baker2• 12 years ago

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• 12 years ago

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

Fasebook2• 12 years ago

A lot of excuses project managers use to ignore technical debt is looking at the opportunity cost of building a new service vs refining an old service and saying "fuck it" and then conceptualizing their choice after the fact as a wise economic decision, then coming back to the problem after it becomes serious, then hiring someone fresh out of college to "fix it" because that's way cheaper then having the original engineer or a professional deal with a tiny fraction of exceptions the right way.

Then they move on to a new job once the debt becomes untenable. This works quite well (as an "economic" strategy) for industries of all types. I bet you can think of a few.

jrs2353• 12 years ago

No need to move on, just declare bankruptcy. The executives and unions do just fine sticking it to the investors in the airline industry.

michaelt2• 12 years ago

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.

atrk• 12 years ago

My experience is just the opposite - systems being hard to adapt to changing models of reality is usually a bigger function of "bad code." If I can understand the code, I can tell that it's "wrong" i.e. that it doesn't match my model of reality. If I can't understand the code, I can't tell whether it's right or wrong, which makes me afraid to change it in case I'm making it wrong-er.

michaelt2• 12 years ago

Well, you can have code that is a fantastic high quality implementation of a flawed architecture. For example:

Backend team: As we are building an MVP, this database table will have a poorly designed schema we will iterate on later.

Frontend team: We need some data that only exists in that other team's database. We will accumulate some technical debt by reading their database directly. This will let us deliver working software quickly.

Backend team: The time has come to refactor that badly designed schema.

Frontend team: That will break everything. You must not do it.

Backend team: Please will you pay off that technical debt?

Frontend team: It's not hurting us much at all, and we would rather be working on new features and things that make money. We are busy and many people are asking us for important things. Here is a link to an article saying technical debt is not a bad thing.

Backend team: I am sad because I'm stuck looking after this badly designed table. I wish I had done a big design up front.

taeric8• 12 years ago

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/ (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.")

Retric• 12 years ago

I agree with what your saying, but the important idea with Technical debt is it's the interest rate and payments that you really need to consider not the capital.

A lot of terrible UI code may be acceptable as it rarely infects the rest of the system where a smaller design bug in a tiny utility library may end up causing worlds of pain even if it's rather elegant code that could be reused on other projects just fine.

lutorm2• 12 years ago

Very rarely can an individual accrue debt that will allow them to make money.

Maybe not make money, but certainly spend less money. Energy efficiency upgrades immediately come to mind. Eating well is another.

joe_the_user3• 12 years ago

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.

seanmcdirmid2• 12 years ago

Very rarely can an individual accrue debt that will allow them to make money.

Our whole financial, investment, and saving system is based on this statement thankfully not being true. You can't successfully save money or value of any kind unless someone successfully borrows it (I.e. Uses it productively).

pm• 12 years ago

I've also seen technical debt accumulate when teams choose to build upon an "MVP" when the MVP was in fact just a prototype. Not nearly enough code is thrown away at the start of projects.

dllthomas• 12 years ago

"Write it, throw it away, rewrite it."

_kulte• 12 years ago

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.

j_baker2• 12 years ago

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• 12 years ago

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

ollysb• 12 years ago

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.

jrs2353• 12 years ago

Sometimes one decides not to pay the debt, instead they declare bankruptcy and start over...

lutorm2• 12 years ago

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.

spullara• 12 years ago

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...

Fasebook2• 12 years ago

correct, technical debt is a very bad thing.

McUsr• 12 years ago

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". :)

jasey• 12 years ago

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.

memracom• 12 years ago

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• 12 years ago

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."

Technical Debt is Not a Bad Thing

Related Stories