The "don't fix it until it's broken" is an interesting discussion. From what you've said, customers and developers can have a very different definition of what

The "don't fix it until it's broken" is an interesting discussion. From what you've said, customers and developers can have a very different definition of what "broken" means, and the customer's definition trumps the developer's. I don't imagine you'd throw out all the refactoring and "cleaning up" jobs though. There'd have to be some consensus case-by-case on what is really broken and what isn't. Managers can overlook some serious code rot just because the front end seems okay. I'm guilty of being the perfectionist though, and it'd be wise of me to keep my pragmatic hat on more often. I'm a little wary of code standards. I've found that they can be a bag full of cargo-culted banalities like "never use break statements", "never have more than one return statement", "the tertiary operator is the spawn of the Devil", "if you use a one-liner if-statement you will hang", or "duplicate all of the version control history by hand at the top of every file". I'd feel much more comfortable if I worked in a small team and we all got together and agreed on some important and useful standards rather than have them dictated by a manager who used to code back in the 90s.