0

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.

  • 2
    Why would something like this be a standard or typical? Every team is different. Some teams are better at estimation than others. Some teams build refactoring time into their original estimates. There's no way for us to know how much time your team will need for refactoring; ask them what their typical refactor time is. – Robert Harvey Oct 26 '16 at 17:51
  • @douglas see "Cone of Uncertainty" – Brad Thomas Oct 26 '16 at 20:10
  • @BradThomas I am definitely aware of that, I even brought it up, especially that in that cone is the best case scenario, when you have an experienced and expert estimator. Which I am not. Though it was kind of shrugged off as an excuse and I was asked what kind of timeframes I can provide again. The largest uncertainty for me is rewriting and refactoring, which I will be doing a lot of during the process as I'm new to the technologies being used. – Douglas Gaskell Oct 26 '16 at 20:40
  • @DouglasGaskell Well it is always expected, however inexperienced you are, that you can provide some kind of estimates... I understand it's a bit unrealistic for management to want a number if you feel you really have no idea, so the answer is to mitigate this mainly by (1) explaining the uncertainty as best you can, which you have done and (2) try to use analysis and research to formulate some accuracy as best you can. Even ask experienced people how long they think it will take you, if you have to. They'll need some idea of your skill level. I've added an answer below also. – Brad Thomas Oct 26 '16 at 21:18
  • @DouglasGaskell The thing is, the refactoring is a bit of a red herring since it's an implementation detail that won't concern management. – Brad Thomas Oct 26 '16 at 21:22
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.

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

0

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.

  • Gotcha. To answer your answer. This has been partially completed, the system is not too large (few thousand ELOC right now), there is no automated testing (Not sure how to justify the time for this, and the time spent learning how to test these frameworks), I am familiar with DRY and SOLID and follow them as much as possible. I'm not sure how good I am at refactoring, I've been programming for ~3 years now, and have often refactored as I went but did not take note of the extra time it took. – Douglas Gaskell Oct 26 '16 at 18:04
0

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.

-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

  • I don't quite understand what you're trying to say here. You say "Never Refactor," but then point out that it has business value. Rewriting from scratch is seldom a good idea: see Things You Should Never Do. – Robert Harvey Oct 26 '16 at 19:33
  • less value than adding features or writing a new version though. – Ewan Oct 26 '16 at 19:39
  • Refactoring time should be built into all estimates. It's pointless and unnecessary to allow technical debt to build up. – Robert Harvey Oct 26 '16 at 19:40
  • you need to learn the lesson from your link. people dont buy 'nice code' they buy features – Ewan Oct 26 '16 at 19:50
  • Then why are you advocating rewriting from scratch? Maybe you ought to read the answer you've written and clarify it a bit. – Robert Harvey Oct 26 '16 at 19:51

protected by gnat Oct 30 '16 at 21:48

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.