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".<p>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.<p>And the more expensive it gets to pay down the technical debt, the less anyone wants to pay to do it.
Technical debt isn't <i>necessarily</i> 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.
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'.<p>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:<p><a href="http://www.slideshare.net/spullara/managing-technical-debt-15539856" rel="nofollow">http://www.slideshare.net/spullara/managing-technical-debt-1...</a>
Technical debt comes down to the ideology of "make it work, then make it right".<p>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?<p>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.<p>- 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?<p>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).<p>As the author mentions, in the context of a startup taking on technical debt. Its much less risky.<p>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".<p>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."
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.<p>"Technical Debt is Not a Bad Thing"<p>"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."