Maybe the independent estimates are way off and developer A takes all kinds of shortcuts that will result in bugs and unmaintainable code while developer B handles the overlooked details and implements a much higher quality solution that requires minimal rework down the line.
There can be massive variations in scope and complexity from one task to another. I'd argue that comparing developers against independent estimates could only be meaningful if the developers are working on the same task independently. Even then, the results could still be influenced by many other external factors. IMHO a time based metric is conducive to sloppy code which will require costly rework. Sure, we have to deliver things on time, but everyone needs to understand that **estimates** are just that and may need to be revised as work progresses on the task, and this can cause the delivery date to change. Also, estimates generally focus on the effort required, not the elapsed time to complete the task - i.e. an estimate of 'two weeks' effort doesn't mean the task will be completed in two weeks from now because some of that time will be taken up by meetings, administrivia, etc. I think a true measure of performance would have to take into account the quality of the solution provided (for code monkeys this may just be the quality of the code, but for developers it involves other things like whether the solution correctly addresses the problem) as well as time and how well the task was managed - did the estimates need to be revised? were they revised? was this communicated effectively? was there anything beyond the developer's control that impacted these measures? Of course, a lot of this is fairly subjective. I'd be wary of somebody asking for such KPIs as it shows that they don't really understand the development process, and that could be a big problem if they're steering the ship in a software company... On Fri, Jun 25, 2010 at 10:17 PM, Jeff Sinclair < [email protected]> wrote: > How about, on any piece of work have someone external make estimates of the > time required. > These are not revealed to the developers. > If everyone is measured against those estimates, even if they are always > wrong, you can at least compare developers. > Obviously there will be some degree of variation in the accuracy of the > estimates but it will give an idea. > If developer A always takes 50% roughly longer than the estimate and > developer B take 150% long it easier to see which developer is performing > better. > > Jeff > > > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of silky > Sent: Friday, 25 June 2010 4:52 PM > To: ozDotNet > Subject: Re: KPI's for software developers > > On Fri, Jun 25, 2010 at 6:48 PM, James Chapman-Smith > <[email protected]> wrote: > > [...] > > > If I were pressed for actually cool KPI I would suggest “Ratio of Test > Code to Production Code”, “Percentage of Code coverage” & “Feature Burn > Rate”. > > It shouldn't need to be pointed out that these are equally flawed (if > not more so, with 'ratio of test to production'). > > > > Cheers. > > James. > > -- > silky > > http://www.programmingbranch.com > >
