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

Question

Hello, I'm trying to build a plan on how we could spend more time refactoring. So I wanted to compare with the industry standards but I have hard time to find studies or metrics on that.

I feel that 20% of dev time spent on refactoring seems a good ratio, but I don't have anything to show for it.

In my mind, for 100% or dev time:

• 50% is spent writing code, debugging, etc...
• 30% is spent writing unit-tests
• 20% is spent refactoring code

So around 1 line of code for 2 written end up being in the shipped product. Obviously design time, documentation time, etc is integrated in these percentages.

What is an industry standard? As a rule of thumb, what is your team using? Thanks, Olivier

Answer 1

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%.

Answer 2

This is depending of many factors like the type of business you are in, the type of process your company use, the type of team you are in, what language you are using, etc.

They are absolutely no right answer. If you are in a field that is moving a lot in the requirement and if the client change a lot and you use an agile method you will be more susceptible of refactoring. If you are in a Bank and you have a team that use a cascade approach you are more prone to write code more and less refactoring.

Answer 3

I'd think such a ratio would vary widely depending on the people, the project, the tools, and likely other things. Typically, however, this would be accounted for under debugging and/or testing, as in a new project it would typically be part of dealing with problems discovered later. There would also be some going on in the initial code writing.

Answer 4

My approach to refactoring is to do it at the same time as fixing things. The benefits of refactoring only ever come when maintaining code, and so there is very little benefit to refactoring code which doesnt have many bugs and doesnt require any new features.

Whenever I'm fixing a bug I look for ways to refactor then, i.e. refactoring time is included in the writing code / debugging category (which I would argue is two separate categories).

Answer 5

I don't really designate a separate amount of time for things like refactoring, unit testing, and documentation. I just consider them to be a part of the finished product, and the job's not done until they are.

Answer 6

What is your design approach? Waterfall? Agile? How big is your project? How big is your team?

The most productive I've been while doing Agile development tends towards 33/33/33, or maybe even 30/30/40. Once you've written the test, and then written the code to pass the test, then you can refactor and hone the code, confident that you're not breaking anything.

On a small project, you can hypothetically architect your code perfectly and never have to test/refactor (I've never seen this actually work). In a large project, or one with many hands in it, or one with many customers asking for many different things, refactoring and tests are far more important than the code itself.

It's like asking, over the lifetime of a house, haw many times you should build the house, how many times you should consult the building code, and how many times you should perform maintenance. Obviously building the house is the most important thing, and in theory, you can architect a 'perfect' house that will require no renovation down the line, but it's unlikely.

You will more likely spend a year or two building the house, and the rest of the house's duration periodically renovating. Reinforcing the load-bearing members is more important than building a deck, even if your clients are asking for a deck. They'll be unhappy, but they'll be even more unhappy if the roof falls in and all they have to live on is a deck.

Likewise, you'd spend X amount of time writing the code, but a larger amount of the time refactoring and optimizing it through the lifecycle of the project.

Answer 7

First point, writing code/debugging/refactoring is IMO a unique activity that should occur during all the project's life. A perfect design doesn't really exist as a design is something ephemeral. Something perfect today can be totally invalidated by new requirements tomorrow.

Second point, I've seen many projects where writing unit tests takes more time than writing code to make them pass.

So to me, ratios are more like:

• >50%: unit tests
• the rest: coding/debugging/refactoring/documentation

Answer 8

For good, well designed code, 5% or less sounds about right to me for ongoing development.

For problematic code that needs serious redesign, you might have to budget a much higher percentage for up-front refactoring, before adding new features or fixing serious bugs.

Answer 9

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 return on investment.

So be ready to answer the question your boss is certain to ask: "why should I?" What are you expecting to gain by refactoring? Will you reduce development effort on new features by 10%? 100%? Will you increase code quality/reduce bugs/reduce support costs? Will you speed up time-to-market? By how much? Will this let you reduce SE or contractor headcount? How many? Or will you be able to add more features per release? There are also negatives: how many features will be delayed if you are given a year to monkey around with refactoring? By how long will they be delayed?

Step 3: do some serious estimating.

So now that you're armed with a design, a plan, monetary justification, and you have the backing of the technical staff, go back to your boss and present your case to him or her. You'll have a lot better luck than saying "we should spend 20% of our time refactoring, some guys on the internet said so."