When creating time estimates for features, is there a standard percentage to tack on for potential refactoring?

Question

Note: I get that refactoring is something you do along the way, you don't treat it as it's own "thing", or it's own specific task. I am talking about refactoring along the way, however I am not sure how much time I might end up spending refactoring or rewriting instead of solely implementing new features.

I've been asked to provide time estimates for each part of a web application I'm building. I'm not too experienced with expected time scales as many of the technologies I'm being asked to utilize, I have never used before. I am providing time estimates as close as I can, however, I know that along the way I will end up refactoring and even rewriting chunks of the application as I become more familiar with the frameworks.

The estimates I can come up with are based on how long I believe it will take to make the feature "work". I do not know how much time I will need to spend to make it work nicely with other parts of the application, as none of them are written yet.

Extra time spent on refactoring and rewriting as I go is an unknown for me. Is there a typical percentage of time that can be tacked onto feature time estimates that can account for potential refactoring and rewriting?

My project manager is not familiar with software development. I am for all intents and purposes alone on this, with some small oversight once the project is done through a couple code reviews with a couple other individuals elsewhere in the company.

Answer 1

No, there is no "standard", it depends individually on you and the tasks at hand. However, especially if you are a beginner, expect your "gut feeling" time estimates to be too low (and that is not just because you underestimate the refactoring time, but also the debugging time, the number of bugs your code will have, and also the "research and learning" time for certain programming tasks).

However, if your estimates are too low by a factor of 1.5, 2, 3 or 5 is something you can only find out by yourself. For this, you can try to estimate a task, measure the effort and compare it to the estimation. Repeat several times, and over the months and years, you might become better with estimations. But don't expect too much, even many experienced programmers are not doing well in estimating bigger programming tasks.

Answer 2

1. If you need clarification on exactly what you are estimating for, ask for that clarification, a couple of times if necessary. Don't ask about whether you need to estimate for implementation details, like "refactoring". The manager is more interested in meeting functional spec. So figure out estimates for everything that it will take to simply make the software function as desired, then add it up. So your job with the manager really is to get clarification on the functional requirement.

2. If your project manager wants a single number as a time estimate, provide that along with the caveat that there is significant uncertainty in the estimate (due in part to necessities like refactoring), and the end result could actually vary widely. Suggest that you could provide a more accurate estimate with further research or prep work. The single number you provide should be something like double your best case estimate

3. Ideally explain the Cone of Uncertainty to your manager and explain why a factor of 4 is actually a reasonable difference between best and worst case scenario in the early stages of a software development project. I.e. you could complete in half or double the time actually estimated.

Answer 3

As is often the case, it depends.

If you are starting from scratch, are you trying to make a decent design up front or just doing it as you go? Less planning will probably lead to more refactoring time.

Are you familiar with the frameworks / language / whatever else? (It sounds like you are not, but I'm putting this in in the interest of having a more complete, general answer.) If you aren't, you will almost inevitably find that you did something poorly. That leads to more refactoring.

How big is your system? A small system can be refactored much faster than a large one.

How much automated testing do you have? A system without tests is dangerous to refactor as you never know what you could have broken. That means you need to do a lot of manual testing during refactoring (and then you still will probably introduce bugs, leading to more work). Manual testing = more time.

Are you following good design principles? SOLID, DRY, etc. will reduce the amount of refactor work you need to do as the system evolves. Copy-paste programming increases it.

How good are you at refactoring? Some people are faster than others. Practice usually makes you better / faster.

There is no standard percentage / amount of time because there is no standard situation.

Answer 4

Refactoring is all about making large changes in tiny steps. I suggest based on your feature size you can factor the time required for this rather than thinking doing in the last stage if you are not prototyping. As others already suggested how much automated test coverage you have makes your refactoring more agile. If you have considered review changes for your feature that should factor your refactoring effort.

Answer 5

Rule one of refactoring : Don't refactor.

The time estimate of a task is basically the same as the cost of that task. Refactoring by definition produces no change in the product the end user sees, so its value to the end user is zero.

Rule two of refactoring (experts only) : Don't refactor.

Refactoring can have value for the business. quicker bug fix times, overall increase in development speed adding new features. less load on servers etc.

However, this value is hard to estimate and you also have the risk of adding bugs into a system which was previously working fine. You would get much greater value with less risk working on a from scratch version 2 instead of rebuilding version 1.

clarification on rewriting.

Every year we see sea shifts in popular technology ideas. no-sql databases, microservices, queue architecture etc. To adopt these new ideas into an existing solution can require extensive refactoring.

However, writing a new version from a scratch allows you to move to the new technology whilst still maintaining an existing product.

Additionally, because of the large amount if refactoring required it will be faster to start again. Enabling you to more fully embrace the new ideas and not be constrained by previous patterns. You end up with a coherent product which fully takes advantage of the new ideas rather than a Frankenstein's monster of technology piled on technology