Technical Debt is Not a Bad Thing | Hacker News Reader

Technical Debt is Not a Bad Thing

sendgrid.com

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.

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.

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.

The lack of contractions in the above exchange really puts it over the top for me.

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

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.

Apologies for a rather late response on this one. I think the "technical debt" view of this would more be that it makes sense to rely heavily on some third party libraries and frameworks to organize and execute your UI.

You are taking out a debt against their knowledge in getting your application off the ground. This directly so if it has to be licensed, but equally true for free frameworks.

My argument is that for many people this will never be a problem. Consider how many games farm out the heavy graphics coding to libraries.

For many software companies and content producers, the content that you are producing is the value they bring. Trying to morph the actual value of a company into a new way of doing this is risky.

Which brings me to a comment I made in another subthread. The one thing people need to remember is that when you take out technical debt by using a framework or library, you are basically entering a contract to do things their way. Take great care when you break this contract.

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.

Actually, this is a perfect example. Energy efficient upgrades can help. However, a large number of them will actually cost more than they a poised to save you. Upgrading the windows of my house, for example, would cost me more than it would save me over the next 20 years. Same with my water heater, HVAC, roof, etc.

Similarly, if you had upgraded to CFLs when they were in their infancy, you would have terrible lights that have a long power cycle and provide little light. (Though, today I get annoyed with family that refuses to buy better lights.)

Most amusingly to me lately, I saw a "call for papers" about converting to DC in the house. Our AC power is effectively "technical debt" in the house hold. Moving from that to a more efficient DC source to power all of your DC items in the house would make sense. Using DC back in the day would not have.

Eating well is an odd one, I think. Rarely are people taking out loans to get food. You can certainly spend your capital more wisely on food, but I'm not sure it fits the metaphor.

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.

I think technical debt is "double" the risk with "double" the reward. I can incur and leverage technical debt to pay dividends now and may never have to pay it back, I may have to pay it back "at cost", or it may cost more in the future due to interest.

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.

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

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.

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"

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.

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

Oh, I do not dispute that there are times and places you can accrue debt to make money. I just dispute that it is something the masses can do. By and large, it looks like something only those at the top and the very bottom can do.

The rest of us? We take out loans to buy houses and cars. Usually of much higher value than we needed. Or, even worse, to buy toys and other household items.

Seriously, when was the last time you took out a loan on something that had a financial return?

Houses can appreciate and are often considered investments. You also need a place to live and you have to consider expenditures made it terms of rent. When considering rents vs. mortgage interest vs. housing cost, there is some point where taking a loan out to buy a house makes financial sense.

Cars are often necessary for transportation. I don't have one, but if I was living in the states they could help me save time and get to work (where I make money). Of course, there is a point where buying a used car with cash makes sense, but there is also a point where buying a car new under a loan makes sense (depends on loan costs, interest, car price, etc...).

Taking a loan out for college can make sense, considering the returns you make afterwards and the lower interest rates often offered through government programs.

I personally haven't bothered with a loan yet (consumer or otherwise, no house or car, but living in China is a bit different from living in the states), but I can see the utility of it.

True, though I argue there is a large percentage of people taking out these loans that basically over leverage themselves.

Consider, there are cars that are perfectly serviceable used or for less than 15k. Yet many people are aiming for cars from 20 to 50k. Then there is housing. Look how well treating housing as an investment worked out last go around.

College is an interesting one. I always cringe when I hear of folks taking out 100-200+k loans for college. That just blows my mind, and has led to both a sense of entitlement for higher wages and general wage inflation.

Though, my economic acumen has reached its end in this post. I do not know enough to really speak whether these loans are terrible ideas.

Interestingly, I think this actually makes it somewhat applicable to the technological debt as I framed it. If the majority of your value add is in leveraged technology, then you will have a hard time of it. Where these lines are between good and bad debt, I do not know.

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.

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

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.

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

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.

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

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.

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.

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

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.

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

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.

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

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.

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

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.

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

correct, technical debt is a very bad thing.

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

Reply on news.ycombinator.com