Technical Debt Is Overhyped. Let’s Talk about Product Debt

This author makes some good points - and I happen to agree. Tech Debt is like any other kind of debt in that it allows for you to have something today that you pay for later.

My personal rule of thumb regarding TD is this: Have we achieved Product Market Fit yet? The answer means a lot.

If we have PMF, then we're working on a product with customers and expectations around performance. Its important to do good work here because in all likelihood, this code is and will continue to be generally long lived. Its OK to take a little extra time and design something that is reasonably future-proof.

If we have not achieved PMF - all bets are off. The customer has no idea how elegant the code is and doesn't care - if there even IS a customer in the first place at this stage. Tech Debt here can be a savior in that taking some well-hidden-from-view shortcuts enables you to iterate faster, get more features in front of a (potential) customer, fix more bugs and generally Learn Faster.

By the time you have PMF you will for the first time know your Real Requirements (and not before). I can't even remember how many times Ive seen perfectly good code scrapped because of a change in direction at an early stage of a product. That was fine too because it was developmental code full of debt. Imagine if we'd fully engineered it only to scrap it?

I propose that Tech Debt can be a good thing in this context.