-2

Does anyone have any suggestions about how to estimate how long it would take to comment and reorganize the code of an entire project?

I just started doing contract work for a company along with another programmer: he's fixing bugs and I'm reorganizing the code. I'd like to make an estimate of how long it would take me to go through the code line-by-line and comment and/or reorganize the code is I go. It's a very large solution: it has two projects, each with multiple files.

It was suggested to me to count all the lines of code in each file, sum it all up, and double your hours to give you padding. It was also suggested that I square the size of the code before estimating. But I don't know how long it's supposed to take to comment, say, 100 lines of code.

Any suggestions would be more than welcome. If it makes a difference, the project is made in Windows Forms using Visual Studio 2012.

Thanks!

jdewitte
  • 131
  • 3
  • 13
  • Are you writing unit/integration tests before you start refactoring? If not, you're probably creating extra bugs for the other guy to fix. Also, what's the goal of this "reorganization"? Are you trying to move the codebase toward some larger goal (testability, maintainability, etc)? Knowing what your end-goal is makes it easier to do a high-level analysis. – Daniel Mann Feb 16 '13 at 18:54
  • 2
    What do you mean "comment the code" - are there legal reasons for it? Or you doing it for personal entertainment? In general code is better when you don't need any comments to read it... Or you mean write architecture overview? Or maybe you mean `` comments for creating documentation? (or Ctrl+K+C to comment out all code - no time at all :) ) – Alexei Levenkov Feb 16 '13 at 19:07

4 Answers4

3

I suggest you pick a small random sample (20 lines) and try to reorganize it. That would give you an idea of how long it takes (if you multiply), and it won't be underestimated, since the randomness of the sample will actually make the work slightly more complicated. You can also do it two or three times, and see if the variance is small. Any other method that is not based on you might be less expensive in time, but will not yield results that are tailored on you. In my opinion this method is a good investment.

0x5C91
  • 3,360
  • 3
  • 31
  • 46
1

First, this is an estimate - estimates are not exact numbers, they are approximations and ranges. The estimate you have at the start may be wildly off once you start getting into it and the estimate would need to be refined. Take into consideration the code of uncertainty when giving an estimate.

There exist many well established models for software estimation. COCOMO II is one of these. I believe that this particular approach has added value to its techniques in that it can work from an already known amount.

A web tool for the COCOMO II can be found at usc. Count up the lines of code you have now. Make an approximation of how many lines of new comments you will need, how much will be able to be reused, and how much will need to be modified. Plug those numbers in. The definitions of how COCOMO II works and all the terms can be found in the usc ftp site

Lets say you have a 10k SLOC existing code of which 75% can be reused, 25% will need to be modified (75% design modification, 100% code modification, ...) and an additional 10% for commenting. There are arguments for and against tweaking the various cost drivers (changing things from 'Nominal' or leaving them as they are).

Plug this in and you get an equivalent size of 2825 SLOC which then translates to 9.2 person months of effort (remember, this isn't just going thorugh the code line by line - but also making sure you have the redesign correct and testing it). Nine months is approximately 1500 work hours.

Consider getting Software Estimation: Demystifying the Black Art which goes into more aspects of what an estimate is and other techniques to do an estimate (this is an estimate by proxy and just one of many techniques).

Remember to save the data on how long it took and your estimate - over time, historical data can help refine estimates.

Further reading on Wikipedia Cost estimation in software engineering

0

You might be able to find nasty bits by using some sort of code analysis that shows you the complexity of the classes.

Checking for code that is not covered by unit test will also help you to find code that is harder to refactor.

Emond
  • 50,210
  • 11
  • 84
  • 115
0

In terms of commenting the code, presumably that means reading every line and describing each method/interesting piece? Ignoring all the usual debate about this, firstly, you have my sympathy, and secondly, I would suggest picking a few classes, and doing the work, and measuring how long it takes: you should be able to extrapolate from there (and add 30% afterwards)

As to reorganising, unless you already know of certain specific large scale refactors you need, my usual answer to "how long will it take" is "how much better do you want it to be?" - and the final answer, always, ends up being a time-boxed amount that is agreeable to both you, and the boss/client. Make a suggestion of x days, and do as much good as you can in that time. Also, someone mentioned integration tests: if this is a viable option, then it will certainly help control the time

Kevin Versfeld
  • 710
  • 5
  • 18