You don't. -- In my experience, you **don't** justify refactoring. By that I mean that you do not list is as a specific separate task, because it gives your manager the ability to choose the development work without the refactoring, which perpetuates the issue. I've spent years as a consultant, being brought in to companies whose development process had gone institutionally awry. I analyzed the situation, looked at the best way to fix the code by keeping the refactoring minimal (for a first pass) but able to solve the biggest issues. I provided in-depth analysis of the most common issues, the code lines that lay at the heart of the issue, the estimated time this added to any development work, and the time needed to refactor it so it ceased being an issue. Every. Single. Time. The response was "we don't have time to refactor, we're busy developing". And it's no surprise you get that answer. Any development team worth any modicum of salt will mention refactoring. Maybe not when things still run smoothly, but definitely once the lack of refactoring is starting to complicate the development work. Any company that persists in refusing to refactor when hitting that milestone, is going to continue refusing to refactor. It's a compounded issue. The lack of code quality causes delays, which makes it harder to reach the deadline, which causes management to cut _even more_ corners to try and get to the deadline, therefore lowering the code quality further, and the cycle repeats. In their defense, it's not management's job to know how to do development. It's your job to provide them with the necessary advice that allows them to make _business_ decisions about the development efforts. If doing development without refactoring is a bad development practice, then the advice you give should not offer it as a valid option. ---- How to not justify refactoring. ---- So I chose to no longer give these managers the implementation details of how development should be done. Presenting development and refactoring as two separate steps implies that management can choose them independently. It's not reasonable to do so, and therefore it should not be presented as an option. When asked to estimate task A, I would no longer say: > Half a day of analysis and prep, two days of work, half a day of testing and refactoring. But I would say > Three days. With almost every client (7 out of 8 by my count), the refactoring discussion and constant corner cutting suddenly stopped and I was able to actually contribute reasonable quality code. This doesn't fix existing issues though, since these tend to require a separate task of their own. It's hard to hide away the refactoring when it's the only job that needs doing. But just like how I started omitting fine details about refactoring being part of the development work I stopped mentioning quick and dirty fixes and how much quicker they could be compared to doing a proper job. When asked how long it would take to fix bug B I would no longer say: > I can quick fix it in half a day, or properly revisit and fix the code in two days. but rather > This is going to be two days of work. ----- To summarize --- There's no restaurant in the world that has a special menu option where they only serve food that did not fall on the floor. The implicit expectation for _any and every_ dish is that the food never fell on the floor. Similarly, you should not present separate options where development happens without the necessary refactoring, because the implicit expectation is that development includes refactoring. Institutional code quality issues in a development team, and persistently denied refactoring effort, are indications that management is making shortsighted decisions that shoot themselves in the foot, but they don't understand how the trigger is connected to the future bullet hold in their foot. In order to protect both the project and the managers from themselves; simply start considering that **essential tasks for development are by definition essential to development**, and therefore fall under the "development" category and don't need to be mentioned separately. All it does is provide a bad option of picking development and excluding refactoring.