5 ms·

Technical Debt is Not a Bad Thing

gtirloni 13y ago
Surely something HN likes to discuss. http://hn.algolia.com/#!/story/forever/0/technical%20debt http://hn.algolia.com/#!/story/forever/0/technical%20debt
carsongross 13y 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_baker 13y 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 13y ago
    I imagine the intersection of those two sets is much larger than either camp is likely to admit.
- Fasebook 13y 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.
  - jrs235 13y 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.
michaelt 13y 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 13y 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.
  - michaelt 13y 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.
    - 13y ago
_kulte 13y 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_baker 13y 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 13y ago
  Is it considered better practice to pay the debt down little by little, or all at once (as in rewrite or feature freeze)?
  - deleted 13y ago
    [deleted]
  - ollysb 13y 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.
- jrs235 13y ago
  Sometimes one decides not to pay the debt, instead they declare bankruptcy and start over...
lutorm 13y 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 13y 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-15539856 http://www.slideshare.net/spullara/managing-technical-debt-1...
Fasebook 13y ago
correct, technical debt is a very bad thing.
- McUsr 13y 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". :)
hersheypowers 13y ago
Almost all committed code becomes technical debt at some point. The more of a debt that any piece of code has is generally correlated to the age of the committed code. Or another way of putting it, all code is ugly code eventually.
jasey 13y 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 13y 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 13y 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."

Surely something HN likes to discuss. http://hn.algolia.com/#!/story/forever/0/technical%20debt http://hn.algolia.com/#!/story/forever/0/technical%20debt

carsongross 13y 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_baker 13y 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 13y ago
  I imagine the intersection of those two sets is much larger than either camp is likely to admit.
Fasebook 13y 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.
- jrs235 13y 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.

michaelt 13y 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 13y 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.
- michaelt 13y 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.
  - 13y ago

_kulte 13y 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_baker 13y 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 13y ago
Is it considered better practice to pay the debt down little by little, or all at once (as in rewrite or feature freeze)?
- deleted 13y ago
  [deleted]
- ollysb 13y 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.
jrs235 13y ago
Sometimes one decides not to pay the debt, instead they declare bankruptcy and start over...

lutorm 13y 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 13y 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-15539856 http://www.slideshare.net/spullara/managing-technical-debt-1...

Fasebook 13y ago

correct, technical debt is a very bad thing.

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

hersheypowers 13y ago

Almost all committed code becomes technical debt at some point. The more of a debt that any piece of code has is generally correlated to the age of the committed code. Or another way of putting it, all code is ugly code eventually.

jasey 13y 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 13y 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 13y 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."