Charlie, I don't mean this in a "RTFM" kind of way, but you would do yourself a service by searching for and reading the previous threads on the topic. I think they would answer your questions.
Rick On Jun 3, 2014 4: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"
