(I'm open to be convinced)
Generally I have witnessed tech debt as something pretty blatant and obvious - generally it's detected in the code review process. Sometimes it's big faults being introduced, more often it's small faults leading to 'death by a thousand cuts'.
My current policy is to allow zero tech debt, following the "no broken windows" principle. https://pragprog.com/the-pragmatic-programmer/extracts/softw... That involves a greater investment in code reviews.
I was in an office that had such a policy - it didn't go well. Perhaps it's a matter of definition, because:
> I hadn't heard of tech debt being something so subjective/invisible that it just creeps in and you have to discover it.
Tech debt is _inevitable_. Any decision will eventually be debt - rot begins before the code is even finalized. Focusing on avoiding short term gains at long term cost is totally fine, and I think that's the point of your "zero tech debt" strategy, but that's not zero tech debt. And even when maximizing for the long-term, you're picking between options, which means you're picking the FORM of your tech debt, not the existence of it.
To return back to my (admittedly anecdotal) experience with "zero tech debt": What happened was a language shift. People would avoid the phrase "tech debt", but still dealt with the reality. The decisions were being made, uncovered debt (such as a paradigm shift in the industry, or a change in dependent technology, or just an anticipated business flow that turned out to play out differently) was hidden. Basically, it seemed fine for a while, but management was getting out of the loop because management had decided an unachievable purity was more important than frank and open communication. The result was what happens any time management pushes themselves out of the loop - at some point, the compound interest on the debt came due. By then, multiple devs had left because in an industry with so much choice, why choose to work somewhere that refuses to face reality?
Not selling the long term for the short term is a great approach, but if you're trying to enforce "zero tech debt", I suggest you talk with your devs to see what they think that means and make sure that you're all on the same page, because tech debt is maintenance costs, and those will never be zero. If you're being told they are zero, then there may well be a disconnect.
I think you are describing tech debt of the "unavoidable" kind. My efforts tend to be focused on the avoidable kind.
Definitionally, no methodology makes the unavoidable avoidable?
Now, let's say you get to that dreaded point - requirements have changed, dependencies have changed, the industry landscape has changed. Which codebase will be easier to adapt - the debty one or the zero-avoidable-debt one?
I feel this is a bit of strawman, though that may not be your intent.
As I mentioned in the above comment, wanting to avoid hurting your long term for the short term is fine and admirable. However, I think the distinction between "unavoidable" and "avoidable" debt is somewhat facile and unrealistic. It's a continuum, with points scattered throughout the center. Is this decision the best one? That is debatable, and should be debated, but the result won't be "yes debt" or "no debt".
I also said that if someone is shooting for "Zero debt" they should talk with their devs and make sure everyone is using words to mean the same thing. I continue to stand by that, because however clean and rational your personal definition may be, it's worthless if that's not the meaning anyone else is using.
Can you expand on what you mean by this?
"zero tech debt", when understanding that tech debt is maintenance efforts at a minimum, is unavoidable. If a workplace has a "zero tech debt" rule, that workplace (the management, assuming they're the ones putting the rules in place) is placing that unachievable purity above the frank and open communication about their very real tech debt.
Where I was at, when "zero tech debt" was the policy, we stopped talking about potential tech debt to management. Decisions were made to avoid short-term debt (good), but no discussion was had about any longer term issues (bad), because we couldn't HAVE those decisions when every choice involves some tech debt.
When tech debt issues arose, we didn't want to surface them, because we'd spend more time trying to justify why this wasn't our fault, wasn't predictable, or taking lumps when it was our decision instead of actually addressing the issue.
Management had placed the ideal above the reality, so they saw the ideal. That didn't prevent the reality, and it left the reality unmanaged. We did what we could - we all took pride in our work and tried to make the best decisions - but the company limited what could be done.
If you are in a team that discourages upgrading build systems, code reviews, code quality, testing etc there isn't really anyone that can point to instances where tech debt was accrued or how much there is.
It is however true with assets; The housing crisis provides a great example; housing is an asset when it is always appreciating; however, if it starts depreciating (2008), it quickly became a liability.
This translates nicely to product. Each feature is an asset for selling; until it is found to have liabilities (pii data storage, inability to scale), then the feature either needs work again (requiring reinvestment) or removed (sold).
