views:

216

answers:

5

We're trying to get a budget together for a new project. We would like to break out code review time separately. What's a good rule of thumb for how many hours of code review are required for each hour of software development? Ballpark estimates and anecdotes are fine.

(Figure a 3 developer team on this one.)

+1  A: 

If the review is done by someone who is 'internal' to the team. Review will be little easy since he/she knows what is happening there on the screen functional wise. So a 40 hour development would take 2-3 hours of review.

If the review is done by someone 'external' to the team. He/She could take up to a day for a 40 hour development. Because reviewer will take lot of time to understand logic than looking standards etc.,

HTH

Broken Link
could you imagine that the external resource for checking code would eventually be just as effective of the internal resource (learning the code base eventually). Or is the external resource generally a different person each time some code needs reviewing?
resolveaswontfix
External person is different each time or can be same. In a big consultancy companies, when they deliver code to client. There are two reviews that should happen Internal, External. Internal is someone with in the team.External could be any technical personal - who is capable/available to review code. So chances are that external is always different person!
Broken Link
A: 

Assuming your code review practices are to have each check-in reviewed by another developer it is probably around 2-5 minutes per hour of code developed. That is of course a real rough estimate.

resolveaswontfix
+2  A: 

I don't think you can actually spec it quite that way. 1 hour of developer time rarely equals a set amount of code that is actually written. Sometimes you have hard problems which may require an hour (for example) of research just to get that one line for a particular method call.

Sometimes you might be breezing through with a fair amount of copy / paste type code in which you could generate a lot to review in a short period of time.

Instead, I would suggest you look at how big you expect the screens to be, coupled with how complex the logic is, then try to derive an amount of code review time from that.

Or, you could just say, let's devote 5% of total project budget to review.. Regardless, it's not going to be based on the number of hours assigned for actually building something.

Chris Lively
+1  A: 

Estimates based on 10:1 to 20:1 ratios (dev-to-review times) are definitely reasonable. Your actual mileage can of course vary a lot depending on cleanliness and readability of the code.

If your team practices paired programming (to some degree, not necessarily full-time), that can increase developers' familiarity with the code under review and speed things up at the review time.

azheglov
+1  A: 

You should be able to review a weeks worth of work in 2 hours. (for one programmer)

Andrew Lewis