Probably a rewrite – HNers always seem to have stories about being brought in to work on companies with incomprehensible rats nests of code that are impossible to extend any further. I bet that's pretty common, more common than technical debt actually forcing the company under.

Still if you really want to take the analogy further declaring technical bankruptcy could cause business bankruptcy (see Joel Spolsky). You probably want to refinance your debt and get onto a repayment plan (an incremental rewrite) instead.

The key part analogy isn't bankruptcy so much as interest. You incur technical debt and you pay it off later in interest (by spending time to clean up the hacky code). If you don't pay off the interest, you end up incurring even more technical debt. Eventually, you could end up paying several times more in interest than the principal (end up spending more time working around the hacky code than if you've just addressed the issue properly in the first place).

Bankruptcy is more correctly letting you get away from obligations to creditors with lesser terms to the creditors than originally agreed because you can no longer pay it back. I think there’s nothing very close to this for technical debt because even in a rewrite there’s new debt involved. A rewrite is a lot closer to refinancing where the value of the asset is re-evaluated and new terms of debt repayment are structured that stakeholders agree to. Most people seem familiar with chapter 7 bankruptcies but there’s 11 and 13 too. Furthermore, bankruptcy is about handling an original amount lended - rewrites oftentimes are done with lessons learned from the original version (rewriting from Python to Go isn’t bankruptcy).

Technical debt bankruptcy is probably closer to shutting down a service / product with no replacement - the effort has already been spent and you’re walking away from costs without caring for the creditors (customers and engineers alike).

The question of whether technical debt can be zeroed in a technical bankruptcy is who the creditors of technical debt really are - is it the business as a whole or the engineers that maintain this stuff?

To me, the state of technical debt bankruptcy is a business in a zombie state unable to grow to service the debts because of the technical debts keeping them uncompetitive rather than something more fundamentally wrong with the business like product market fit or bad reputation.

Bankruptcy occurs when your debt exceeds your ability to it off. I suppose that would be the point at which it's easier and cheaper to write new code than try to fix the old code. The debt can no longer be paid back. That said, somehow there are still COBOL programs running, so even though that program should shut its doors and liquidate any useful assets, real world money prevents that from happening.

oh it definitely is a rewrite