I don't agree with the first part. I have worked enough time on the management side to understand that management is always driven by business value (it's their

I don't agree with the first part. I have worked enough time on the management side to understand that management is always driven by business value (it's their job). So your point 'Let new [...] drive your changes' is valid to some extent. But business value doesn't always mean that you need new features to justify working on a project. Sometimes it is possible to justify working on something just by explaining technical debt and how much time it will cost in the future (e.g. slow you down). Working in an unstable environment can drive you crazy as a developer and lower your productivity enormously. So if you don't talk about the issues in the code base with the management, they might wonder why you have lower output then others and classify you as a slow programmer. Instead, I think you should bring the facts to the table (slow down factor (number of bugs, time to trace them down), risks (likelihood of production issues)), in terms of how much time it costs to work within the current code base and let the management decide on how to proceed (make sure to bring a recommendation). If they are willing to let you spend time on improving the quality, try to modularize it so that if the rewrite will be stopped at any time, the time you spend refactoring it helps you in the future. While doing so, show respect to the programmer that worked with that code base in the past (even if she/he create that mess). You don't know under which conditions she/he had to work, how she/he learned to programme or what her/his life looks like outside the job. The management basically has these options: 1. just minor changes to the code base: no rewrite, no hidden quality enhancements (might be a valid option if an alternative software is being developed already). 2. hidden improvement: no rewrite, but you are allowed to spend some extra time to improve the parts you are working on. 3. restructuring of the code base and systematically writing tests for different modules (recommendation). 4. complete rewrite: unlikely to happen unless it is cheaper than 2 and 3. If the management decides to continue with option one or two, do the best you can under the circumstances be pragmatic as caymanjim wrote. Make sure to include option four so that the management sees the full spectrum of options at hand.