On Sat, Jun 26, 2010 at 12:18 AM, Matt Siebert <[email protected]> wrote: > 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.
Agreed, it's a bad approach. > 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 .... yes. Of course, a KPI, from an external point of view, *is* the quality of the solution. It's basically the definition of quality. > (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... -- silky http://www.programmingbranch.com/
