> Even with clean code, you will have technical debt because as the business evolves, your code becomes stale. Suppose the ideal clean code base. There is of c

> Even with clean code, you will have technical debt because as the business evolves, your code becomes stale. Suppose the ideal clean code base. There is of course no stale code there. In the event of new business requirements, it has been reconsidered carefully and rewritten to cover the new requirements in a way that's architecturally consistent. If that was impossible with some previous iteration of the architecture, the overall architecture has also been reconsidered and changed. For your jQuery example, with unlimited resources available to address code smell, you'd of course either replace it with some existing higher level library that suits your use case, or you'd write your own high-level generalizations. I have seen a lot of code that was terrible not because they had unwieldy business requirements, but frankly because the code had poorly considered abstractions and unclear boundaries. Features were added without consideration for the architecture. Quick and dirty fixes were considered preferable to overhauls. Short term workarounds ended up being long term don't-touch-this-we're-not-sure-what-it's-doings. What worked at some thousand LOC became the guiding principle for further additions. The real problem is that rewriting or cleaning up can become unbearable for some combinations of organization and code base. It takes time and can become an organizational hurdle if people are simultaneously implementing new features or fixing bugs. Every time a developer says "this will take several weeks to implement" and the project owner successfully insists that it can't, the code base gets dirtier. In the real world some PPM of fecal matter is acceptable because getting the last few particles out is going to increase the cost by an order of magnitude.