Re: No time to refactor

Absolutely totally agree with this. If you're dicking about with a piece of code anyway, I as a manager trust your skills as a competent engineer to leave that code better than you found it. If we have to test it again anyway then fine. But start changing code that we've tested and is a known quantity and you're entering a world of pain. It's just wasteful, and wouldn't you rather be off doing new shinies than having a manager scowling at you for introducing risk?

Developers always want to refactor code. It's actually a developer's nature to move code about and fiddle with it - it helps to understand it and know your way around it. However, to a QA guy, code that's been tested has been tested. Any changes to that code erodes the money that's been spent on testing that code, which then must be tested again (so you're costing QA twice). Managers are trying to keep devs happy with new and exciting shiny things and also suits happy with new features. Managers also have to perpetually answer questions like "why are you spending time rewriting the thing we've shipped instead of adding new IP and value to the company?".

You could argue that refactoring code saves the company money by creating a new and "better" bedrock for future development. I've never know that to be the case in reality. Feature requests and road maps change so fast that you either generify your product out of existence or your refactor yourself down a dark alley.

Ultimately, apart from "but the developer likes it" there is no justification from any angle to introduce change for change's sake.

Even as a developer, it's a right bastard finding that someone moved your code around and introduced a cut and paste bug.