Code write \ code review productivity

V

Volodymyr Sadovyy

Hi.

Can somebody refer me to resource with specified/analyzed/approximated
productivity in Java coding and Java code review tasks? Coding
productivity is more described in the net, but I didn't find anything
about code review productivity...

Thanks,
V
 
R

Roedy Green

Can somebody refer me to resource with specified/analyzed/approximated
productivity in Java coding and Java code review tasks? Coding
productivity is more described in the net, but I didn't find anything
about code review productivity...

There are two sorts of question you want to know:

1. how productive is this person capable of being?

2. is this person slacking off?


The first can be answered by given each person to be measured the same
task. At the end of the day you measure the quality (smaller is
better), and % complete.

The second can be measured by asking several people to estimate time
on each task, and also statistically measuring how much over/under
each person is when he is actually assigned that task. You have to do
this over months.

The problem with the sorts of productivity measures I have seen, is
they encourage verbose pedestrian solutions to crank up the line
count.
They also discourage putting in time now to save time later in
maintenance.
 
X

xarax

Roedy Green said:
On Fri, 23 Apr 2004 11:34:41 +0300, Volodymyr Sadovyy
/snip/

The problem with the sorts of productivity measures I have seen, is
they encourage verbose pedestrian solutions to crank up the line
count.
They also discourage putting in time now to save time later in
maintenance.

Management claims that quality is highest priority, but
don't slip the delivery schedule. There's never time to
do it right the first time, but there's always time to
fix it after delivery.
 
J

Jeff Schwab

Roedy said:
There are two sorts of question you want to know:

1. how productive is this person capable of being?

2. is this person slacking off?


The first can be answered by given each person to be measured the same
task. At the end of the day you measure the quality (smaller is
better), and % complete.

Nonsense. Size and quality of code are almost unrelated. % complete
can be very difficult to measure in any meaningful way.
The second can be measured by asking several people to estimate time
on each task, and also statistically measuring how much over/under
each person is when he is actually assigned that task. You have to do
this over months.

Also nonsense. The fact that one person estimates too aggressively,
while another sandbags, does not mean either is slacking off.
Interestingly, this test seems to be a decent way of measuring the
answer to #1: How long does it take for a person to achieve some
quantifiable goal, e.g. a certain level of testable functionality in code?
 
P

Peter Pan

Volodymyr said:
Hi.

Can somebody refer me to resource with specified/analyzed/approximated
productivity in Java coding and Java code review tasks? Coding
productivity is more described in the net, but I didn't find anything
about code review productivity...

Thanks,
V


Seems like there is a tool called Klockwork can do help to you. You can
search from google.
 
R

Roedy Green

Also nonsense. The fact that one person estimates too aggressively,
while another sandbags, does not mean either is slacking off.
Interestingly, this test seems to be a decent way of measuring the
answer to #1: How long does it take for a person to achieve some
quantifiable goal, e.g. a certain level of testable functionality in code?

That is not what I meant. I meant you can get to know if a person over
or underestimates the time and by how much. That has nothing to do
with productivity, just optimism. You can then see if he is taking
longer than usual or less than usual on some other project using just
his adjusted estimate or with the adjusted estimates of others. That
is a measure of slacking off.
 
J

Jeff Schwab

Roedy said:
That is not what I meant. I meant you can get to know if a person over
or underestimates the time and by how much. That has nothing to do
with productivity, just optimism. You can then see if he is taking
longer than usual or less than usual on some other project using just
his adjusted estimate or with the adjusted estimates of others. That
is a measure of slacking off.

What do you mean "usual?" Some projects take longer than others, and
the quality of the estimates is likely to vary from one project to the next.
 
R

Roedy Green

What do you mean "usual?"

The more data you collect the better you can project the actual to
projected ratio of any given programmer.

I hate making time estimates. The only things I can estimate
accurately are stuff that is so incredibly boring I know exactly how I
will do it before I start.

You can identify the tricky areas, but you really have no idea how
tricky they are until you have at least chewed on them for a few
hours.

Dollar estimates I feel better about. I don't mind working for less
on challenging work.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,480
Members
44,900
Latest member
Nell636132

Latest Threads

Top