Nice straw man. Nobody said "all code will be rewritten every 2-3 years". He said "most code" will be rewritten every 2-3 years. Also, like I said, these were values on his team. We were a front-end application and every 2-3 years Netflix would rebuild their player UI which usually involved a complete rewrite.
I'm just saying that if you have it in your head most code is going to be rewritten every 2 years, it's understandable if you don't bother making things easy to work on, and just hack it together.
An argument that "eh, most code is rewritten anyway, who cares" is what I'm reacting to, and have seen countless times myself.
But I don't want to say there is never a time someone will say, "this code is going away, don't spend too much time fixing it now" and it's really really good advise.
Its funny that you mention specifically this related to UI code. I was thinking about it after your first comment, and basically every product that I've worked on that fit this style of development has been UI related. And indeed, most UI projects have had almost complete rewrites every 2-3 years for one reason or another.
The ones that didn't were effectively stalled projects. This makes me think that technical debt really can be thought about in a completely different way for frontend code in many cases.
A few years make sense for UI for consumer products. The evolution of displays has been tremendous in the last decade and a half. Desktop screens have doubled in size and resolution, while mobile and tablets just appeared overnight and when from nothing to where they are today.
Products have changed, but also UI design tends to be driven (or at least influenced) by marketing. And marketing trends change regularly driving a need for markup and styling to be revisited.
In theory, this is just marketing, but in practice if often turns into much more.
