Sins of software development

And with methods like TDD: "don't touch it or else you will break 1500 pointless unit tests that don't correspond to any actual functionality and will have to be rewritten". But you can, with great confidence, make changes which, so to speak, shuffle the same technical debt among different accounts.

Here's an alternative point of view - Technical Debt is the way that software grows when people take the easy route. If it's easier to add code to an existing method than it is to add a new method to a class, then it shouldn't be a mystery why there are so many large methods.

The reason software goes bad is because bad is easier than good.

Not specifically to TDD, but tests are one of the things that helps keep that particular complaint from being used. You -can- refactor with some assurance that you won't break anything (as the tests will either continue to pass, or they'll break, and in investigating them you will confirm that your changes broke only the things you intended to change). Without tests, refactoring becomes a "Well, we don't -think- we broke anything..."; you have no reassurance that you didn't.

>I'd posit that technical debt gets created because of time pressure, and that it stays because of continued time pressure

I think you could boil everything down to "time pressure" and not have any good insights on a problem. For us our technical debt came in the form of resource constraints, namely not having enough money to hire someone to be able to do a task in the most optimal way. Sure we didn't have years and years to learn a new codebase but I don't consider that "time pressure" in the same sense.

I do think in general though if you are "hacking" on a product, you are almost by definition not building it in the most optimal way. In general things are left out or overly complex, whether it be documentation or streamlined code or building with a non-native SDK instead of native development technical debt sneaks in there.

What nearly all discussions (every?) of technical debt miss is technical debt interest rate, product value and product interest rate. It's not a problem to carry debt if the interest rate on it is lower than that on your product and its level is lower than your product's.

I like to build cleanly, but sometimes a feature needs to be in production TODAY, so we get it into production TODAY. Or sometimes it's useful to get something into production/usage before investing too much into building it. In fact, I'm about to commit a cleanup to a "get it into production TODAY" bit of code that I wrote 3 months ago and I'm very appreciative of the fact that I got a second crack at the problem: the revision is much more general, has better test coverage, is extensible because the feature has been in production for 2 months and I understand it better now that we've been using it. I would have wasted time and money building it more cleanly 3 months ago.

As parts of the product get larger and more complex, we carve them off into their own products/services/systems so that we can more easily reason about the value, debt and interest rates. To be sure, all of these measures of debt, value and interest rates are very subjective (...in the early days ...perhaps they can be measured in various ways later on), so I'm not suggesting that we sit around saying "the debt on that would be $4,729 and the interest rate would be 39.16%". But they're useful analogies and are helpful to keep in mind and to guide discussion. And, besides, you probably don't know your exact credit card balance and interest rate at this exact moment* but you probably have a decent estimate/feel of/for it.

The problem with technical debt is not technical debt; it's that most people are blind to it. Just as with a credit card, they just swipe the card and, hey!, new stuff!; they just commit the code and push it, and, hey!, new feature! When the bill arrives, they're surprised. Just as with financial debt, technical debt is a tool. Just as with a physical tool, you can use it to hurt yourself.

I run the product/dev group for a startup and we are constantly accruing and paying off technical debt. We do so very consciously and very openly, while constantly thinking/asking: if we do this quickly and accrue debt, when will it need to be paid?; will it slow development of other parts of the system?; did we accrue a debt without noticing it?; how much debt are we paying-off/cleaning-up this week? And I'm clear with the rest of the management team about where and when we're accruing debt and they use that knowledge when considering product/dev requests. IMO, it's critical that your company and team have a philosophy about technical debt recognition, accrual and payment.

* 3... 2... 1... A pedant just checked their balance and interest rate...