[mjlawson]

Zero technical debt certainly is... ambitious. Sure, if we knew _what_ to build the first time around this would be possible. From my experience, the majority of technical debt is sourced from product requirement changes coupled with tight deadlines. I think even the most ardent follower of Tiger Style is going to find this nigh impossible.

[zoul]

I would even say that from a project management perspective, zero technical debt is undesirable. It means you have invested resources into perfecting something that, almost by definition, could have waited a while, instead of improving some more important metric such as user experience. (I do understand tech debt makes it harder to work with the codebase, impacting all metrics, I just don’t think zero tech debt is a good target.)

[lll-o-lll]

> perfecting something that, almost by definition, could have waited a while

No technical debt is not the same thing as “perfection”. Good enough doesn’t mean perfect.

Would it be ok to submit an essay with only 90% of the underlined spelling mistakes fixed? Do you paint your outdoor table but leave the underside for later?

Do it once, do it right. That doesn’t mean perfect, it means not cutting corners.

[zoul]

Would you keep fixing the underlined spelling mistakes on your “watch out for holes in the pavement” sign while people are already walking there?

[lll-o-lll]

There are contexts where quick and dirty and (hopefully) come back later are warranted. Far more often it is just an excuse for shoddy work. You used the word “perfection” as the contrast to “technical debt”. Granted, technical debt is not a well defined term, but I am simply highlighting that “free from technical debt” in no way implies anything like perfect. It just implies well made.

[zoul]

My argument works just as well if you replace “perfecting” with “improving”.

[skydhash]

Technical debt is not a current defect. It just means that for the sake of having something quickly done today, you accept that the cost of changing stuff tomorrow will be greater than normal. If you never have to change something (switching jobs, consultancy project you don’t care about,…) then it may be a great trade off.

[NeutralCrane]

Ironically, some of the worst tech debt I’ve ever dealt with has been because the initial implementation was an overengineered disaster by an dev who thought they were solving all possible problems before we really understood what all possible problems are.

“Zero tech debt” is an impossibility. The most elegant solutions incur some kind of tech debt, it’s just less than others. More realistic than “zero tech debt” is a continuing dedication to addressing tech debt combined with using implementations that minimize “one way doors”.