Charlie, I have a long standing hatred of performance metrics, that I won't go into the background for here, but I'll attempt to answer the basis of your question.
Where I work currently, we went through an 'Agile transformation' a few years back. We all went through training on how to develop in an agile methodology, we discovered scrum masters, sprints, and all of the 'wonderfulness' of the agile methodology. During our grooming sessions we played Agile Poker (http://en.wikipedia.org/wiki/Planning_poker) to estimate the level of effort of a given change. The 'points' assigned to the modification gave an indication of how hard the change would be, and a 'velocity' was set that said...ok, during this sprint we can handle '50' points of effort, with a sprint typically lasting 2 weeks, it would be agreed by all parties involved that the team could develop and test those 50 points in that 2 week period...it is typically assumed that given a general scrum team that the velocity can increase x% each sprint as the team gets into the groove. This process worked well for awhile until the 'metric' folks got a hold of these numbers. The metric folks said ok...well, we will start measuring teams on performance based on these 'points'. They started saying that this team was doing more work than that team because they were handling more points during a sprint...so one team started taking 3 0's onto the end of all of their points, they were then doing 1000 times more than any other team, and it became abundantly clear to the metrics folks that a 'point' system didn't determine how efficient a team was. Even within my scrum team our point values varied....if I was doing the work, I would assign the effort a 2 or 3...but if I knew that I wasn't going to the be the one doing the work, but instead, a junior member of the team, I would assign it a 5 or an 8 because they would need to do more research into the system to figure out how to get it done than I would because of my time on the team and knowledge of the inner workings of the app. The fact that myself and the junior member of the team might generate the same code, and I would do it faster, doesn't indicate that I'm better than them, nor necessarily more productive...just have more background than another. So...this long story is to say that every time I have ever encountered a performance metric that someone is trying to use to evaluate 'who is better'...I find that any metric that says 'lines of code per hour' or 'objects per day', etc don't show enough of the picture to properly evaluate someone. I instead prefer a metric that works on the whole environment/person instead. I prefer to look at 'how does the developer interpret requirements, does the developer ask any questions for clarification, how efficient is the workflow that is developed, how many defects come back on the code that is developed, etc. As others have pointed out....400 objects that don't work well are worse than 20 objects that work well. Other factors that determine a good developer are ability to communicate with team mates, ability to communicate with management, and ability to communicate with the customer. Some people are so 'heads down' that they might be able to program anything you want, but if you can't articulate your 'needs' to them in a way that they understand, and them get you what you are looking for back out of that...then they aren't a good developer in certain situations. I would be happy to take this offline with you if you would like...maybe get a bit more into your reasons for looking for this metric. On Tue, Jun 3, 2014 at 5:03 PM, Charlie Lotridge <[email protected]> wrote: > ** > LJ says 'performance metrics suck and don't work the way they are > intended'. So, do you feel strongly about this? Yikes! ;) > > Really, though, while I didn't participate or even see any of those prior > conversations about this subject, a couple points occur to me... > > First, while you're of course entitled to your opinion, I hope your > blanket dismissal of the subject doesn't discourage others from voicing > theirs. If the topic annoys you - and it seems to - my apologies. Not my > intention. > > Second, I'd agree that "no one metric can accurately" say anything about > anyone. My "one metric" examples were just given to spur the conversation. > And perhaps others have more nuanced answers that involve more than one > metric and include qualifications. I'd be interested in hearing about > those. As a software engineer (my background), one of the metrics that > has been used to judge my work has been "lines of code". In and of itself > it's not a useful metric, but combine with other factors it can help > provide a broad picture of the performance of different developers. > > Third, having such data doesn't make it bad or "wrong" data, it depends on > how the data is used just like any other data. If used constructively, > such metrics could, for example, be used to help assess a developer's > strengths and weaknesses with perhaps the goal of working/educating the > developer to shore up those weaknesses. And while it's certainly true that > information like this can be misused, it doesn't mean we shouldn't have the > conversation. > > Fourth, there ARE clear differences in the performance of different > developers. Sometimes there are very valid reasons to judge the relative > performance of developers. Sometimes it's because hard choices have to be > made like downsizing. Is it better in these situations for the manager to > just pick the individual(s) they like the least? Or who they *think* are > the least productive? I smell a lawsuit. Wouldn't hard metrics be useful > in these cases? > > Finally, a disclaimer: I don't now or have any near future plans to use > such metrics to evaluate anyone...I don't have anyone to evaluate. And > while my interest in the topic is more than just idle curiosity, I won't be > using it to fire anyone soon. For me, this information is more for > research purposes. > > Thanks, > Charlie > > > On Tue, Jun 3, 2014 at 3:03 PM, LJ LongWing <[email protected]> wrote: > >> ** >> My opinion is that 'performance metrics suck and don't work the way they >> are intended'. There has been healthy debate over the years regarding >> exactly that subject, and every time it's happened, either on the list or >> otherwise, it ends up being that no one 'metric' can accurately say that >> this developer is doing 'better' than another developer. >> >> >> On Tue, Jun 3, 2014 at 3:46 PM, Charlie Lotridge <[email protected]> >> wrote: >> >>> ** >>> Hi all, >>> >>> I'm curious...what are your opinions about what might be useful metrics >>> to use to judge the performance of Remedy developers? To narrow the >>> conversation a bit, let's just talk about during the creation of a new >>> custom application, or custom module to an existing application. In other >>> words for code generation. >>> >>> So for example, you might tell me that a good developer can create at >>> least 50 logic objects (active links/filters/escalations) in a day. Or >>> create & format one form/day. >>> >>> What are you opinions? >>> >>> Thanks, >>> Charlie >>> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> >> >> _ARSlist: "Where the Answers Are" and have been for 20 years_ >> > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
