I want to talk about a word problem. Developers ask product managers for “cleanup time” and product managers say no. Then developers get frustrated and say the business does not care about quality. I have been on both sides of this table, as a developer and as an agency owner who paid the bills, and I think the problem is not the product manager. The problem is the word cleanup.
Cleanup sounds optional. Cleanup sounds like something you do when the real work is done. Nobody funds cleanup when there is a deadline, and there is always a deadline. If you frame refactoring as cleaning, you have already lost the negotiation.
Martin Fowler defined refactoring very precisely in his book, and the definition matters. Refactoring is changing the structure of code without changing its behavior, to make it easier to understand and cheaper to change. Read that last part again. Cheaper to change. That is not a hygiene activity. That is an investment with a measurable return, and we should talk about it that way. His site has the whole catalog if you never read it.
The economics nobody writes down
Here is the thing every experienced developer knows but rarely says with numbers. The cost of a feature is not fixed. The same feature costs three days in a healthy part of the codebase and three weeks in the swamp. Same feature, same developer, ten times the cost. The difference is the structure of the code around it.
That difference is the whole business case for refactoring. When I refactor a module, I am not making it pretty. I am lowering the price of every future change in that module. If the team touches that module every sprint, the investment pays back in weeks. If nobody has touched it in two years, the investment pays back never, and I should leave it alone even if it offends my eyes.
This second part is important and developers do not like it. Ugly code that nobody changes is not debt, it is a closed room in the house. It costs nothing. I do not refactor for beauty. I refactor where the team is about to work, because that is where structure converts into speed. Kent Beck writes about this economic view of code changes and it changed how I plan my work.
What worked for me
So how do I turn this into a funded ticket instead of a rejected request? Three things have worked for me, both at Benevity and back in my agency days when the client was paying by the hour and questioned every line of the invoice.
First, never open a generic ticket called “refactor the billing module”. Attach the refactoring to a business goal. Say it like this. The next three features on the roadmap all touch billing. Today every change in billing takes about two weeks and produces bugs. If we invest one week restructuring it first, each of those three features gets faster and safer. We spend one week to save several, and we cut the bug risk on the part of the system that touches money. Now the product manager is not funding cleanup, they are buying speed on their own roadmap.
Second, use the defect history. Pull the incident list for the messy area. Every production bug has a cost, the hours to fix it, the support tickets, sometimes a customer credit. If the same module caused four incidents in six months, you have a number. Refactoring that module is risk reduction with a price tag, the same way insurance is. Product people understand insurance.
Third, stop asking for permission for the small stuff. Fowler calls it the boy scout style, leave the code a little better than you found it. Renaming a confusing variable, extracting a function, adding a missing test, that is part of doing the task, not a separate project. A surgeon does not open a ticket to wash hands. Reserve the negotiation for the big structural work, and do the small tidying as part of professional work, inside the estimate.
The honest part
I have to be honest about the other side too, because I spent eleven years signing the checks at my agency and it taught me respect for the budget. Not every refactoring is a good investment. Developers sometimes use the word to fund a rewrite they want for emotional reasons. We have all met that developer. Sometimes that developer is us . If you cannot say which future changes get cheaper, and roughly by how much, then it is not an investment yet, it is a wish. The discipline of building the business case protects the team from the bad refactorings too, and that builds the trust you need for the good ones.
The deeper point is about team health. Teams that work in a swamp slow down a little every quarter, and slow teams get pressure, and pressured teams cut corners, which makes the swamp deeper. Refactoring, framed and funded as an investment, is how you break that loop before it breaks your people.
So drop the word cleanup from your vocabulary. You are not a janitor asking for permission to mop. You are an engineer proposing an investment with a return. Talk like one, and bring numbers.
Pax et bonum.