"Code quality" should be about readability. And by "readability" I mean "can the function/module/system be understood by the individuals on the team fairly quic

"Code quality" should be about readability. And by "readability" I mean "can the function/module/system be understood by the individuals on the team fairly quickly?" Just because someone doesn't like the indentation, or the looping style, or whatever opinions they have ... these things don't make code quality poor. If you can understand the system, make changes, and add features without bringing down large parts of the system, it's probably fine. The problem as I see it: companies prefer the inexperienced devs because they're less expensive, and as a result, their inexperience leaves them frustrated with code that they "don't like." They then attempt to sell management on a rewrite on these grounds. The team can only deliver features that customers want, on the schedule the business wants, if the underlying infrastructure of the code allows it. If the code infrastructure forces me to spend too much time implementing features, and feature requests continue pouring in, then there will never be time to refactor because there will always be "pressing feature demands."