[smileysteve]

> when you enjoy zero tech debt and an excellent foundation.

This implies that you plan exactly when and where tech debt is accumulating or found. The scrum argument is that by iterating and releasing, you find out where unexpected tech debt is more rapidly; and you go back and fix it.

One way that #AgileIsDead happens is when products disregard the tech debt for features even as it becomes apparent.

[vemv]

Interesting, I hadn't heard of tech debt being something so subjective/invisible that it just creeps in and you have to discover it.

(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.

[ergothus]

> My current policy is to allow zero tech debt

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.

[vemv]

Great insight.

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?

[neeleshs]

Software development is a never-ending procession of tradeoffs. In that context, tech debt and paying it is also a never ending procession. A code reviewer may say a 2 level deep if/else is more readable. But two layers abstraction while complex, may be more adaptable later on. Then again, one may never need it at all. So unless one has a crystal ball, tech debt is mostly visible after the fact. There are some areas that may qualify as "universally accepted", but in my experience that is a much smaller piece.

[ergothus]

> 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.

[vemv]

Point taken.

At the same time, I'd note that anything can be debated ad nauseam, so nearly everything can be considered subjective.

So indeed I can't aim to 0.00000 tech debt, nor identify "avoidable" tech debt with 100% accuracy.

But I _can_ follow certain practices and have a given team follow them. Those practices being quite objective, benefitial, and superior to the status quo of the industry.

[dmix]

> because management had decided an unachievable purity was more important than frank and open communication

Can you expand on what you mean by this?

[ergothus]

> 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.

[foobarrio]

One of the reasons why I sometimes don't like the term "tech debt" is because you can take it on without knowing it. This is not true for financial debt. When you borrow money, even if you're not tracking it, the lender is 100% tracking the debt.

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.

[smileysteve]

> This is not true for financial debt.

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).

[foobarrio]

That's a good comparison I haven't thought of before!