What is a good ratio of refactoring time versus development time?

Your comment says that you have millions of lines of code but no unit tests, and that you are having a hard time convincing management that unit tests are worth it. According to Fowler's book, refactoring needs to be accompanied by unit tests to provide the confidence that you're not breaking anything while you refactor. I would agree, and I'd suggest that unit tests are going to provide more value than anything else at this stage, so aim first for that goal. I strongly recommend Michael Feathers' book "Working Effectively with Legacy Code" for suggestions as to how to do this. You don't even have to write more than a few unit tests to make it a worthwhile effort, just get the framework running.

Step 0: get an automated unit testing framework harnessed into your code.

You're not going to try to accomplish this alone, are you? This is a big project, and I expect you are part of a senior technical team who shares the pain with you. You need to get all of them to buy into this 100%. You'll need their backing when you go to your boss, you'll need their expertise to share in creating the design, and you'll need their total agreement on the design.

Step 1: gather a posse.

Without a plan and a goal, refactoring isn't going to help much. Are you hoping to just to chop the code up and make modules smaller? Are you going to get code organized into domains? Are you going to try to wedge some service interfaces into it? Are you going to refactor to an n-tier architecture? What do you and the posse think needs doing? And how are you going to communicate this design and refactoring plan to the SEs?

Step 2: get the posse to do some initial architectural design and planning of the end state.

Now for the hard part. You're asking for 20% of 30 engineers' time, which is probably over $500,000 per year. You're going to need a lot more justification than "accumulated technical debt." You're going to need to show ret

I doubt there are any norms.

To your breakdown: most teams do not write unit tests and do not refactor (until something breaks or stalls development). Most commonly, refactoring time allotment is < 1 %.

If you're interested in good practice then....

• Refactoring may be an ongoing activity as part of the development process. You see an improvement potential and you personally assign some small time to make things better. Here refactoring time < 5%.

• You perform regular code reviews. Say, once in a few months. Then you can dedicate a few days exclusively for the team to only review their code and improve it. Here also < 5%.