Um, what? No! This is exactly the type of logic-wrangling that happens with bad mental models.
It is not going bankrupt on that code, When you go bankrupt, there is a huge penalty to your credit! If you stop maintaining code that no one uses, the drag goes away and there is no downside!
Deleting code is fun. Going bankrupt, not so much.
When you "go bankrupt" with code, there's often a huge penalty to your user experience. Presumably that code existed so you could do something and make things better for your users. If you take it away, or even stop maintaining it, you're doing less for your users.
This is why I like the "technical debt" metaphor more than the "technical drag" metaphor. Technical debt acknowledges that there's an outside user who's presumably paying you for the project. You can choose to satisfy them better now, but it's at the cost of satisfying them less later, or even regressing and making things more painful for them as you take away debt-ridden features. Just as how financial debt lets you invest now and satisfy the immediate customer better at the price of paying it off later.
"Technical drag" implies that forward motion is inexorable, and the only variable is the rate. This is not a given in software; I often try to use old versions because I know that new ones will be slower, more cluttered, and buggier.
When you "go bankrupt" with code, there's often a huge penalty to your user experience. Presumably that code existed so you could do something and make things better for your users. If you take it away, or even stop maintaining it, you're doing less for your users.
Did you read the article? Eric Ries gave a good example of a piece of code that they had built, with technical debt, and which they threw away because it had little or no customer value.
In practice, I see it happen all the time. There's functionality in most applications that could probably be removed with little impact to user experience. Even on Woobius there are some chunks of functionality that are not much used at the moment and that we could remove without much impact on the users.
Of course, but I was responding to the comment, which was about calling it "technical debt" vs. "technical drag".
We could just call it "technical venture capital". You make a large number of investments, the majority of which have absolutely no value to consumers. You abandon the losers, sometimes after much handwringing. It is usually impossible to tell a priori which features will be winners and which will be losers, though experience and good technical judgment can improve your odds. You can invest more in promising features to bring them to market quickly. Doing so usually introduces lots of warts into the codebase which will have to be fixed later - but then, you'll have lots of money later to fix them. But you have to be careful to avoid investing too much too early, before you've seen how the feature will actually play out, because then you build a giant monstrosity that collapses under its own weight before it can ever get to market.
Or we could accept that all metaphors are imperfect. I'm going to continue calling it "technical debt", because most people - even if they haven't heard of the term - have some idea what I'm talking about when I mention it.
which they threw away because it had little or no customer value
It's easier to type that sentence though than it is to actually come to that conclusion. Assessing customer value, or even better, which customer between two competing customers matters more is the hard part.
You don't solve technical debt with technical decisions, as it's a symptom of business process scope creep.
Unnecessary code is not technical debt. Code supporting unnecessary process is technical debt.
It is not going bankrupt on that code, When you go bankrupt, there is a huge penalty to your credit! If you stop maintaining code that no one uses, the drag goes away and there is no downside!
Deleting code is fun. Going bankrupt, not so much.