The thought of trying to measure something as fungible as development -- given that there is usually more than "nine way to skin a cat" in Remedy -- tends to make me believe the idea stems from a manager with far too much time on their hands.
And as far as measuring development, I would think you would have to give excruciatingly exact development tasks to each of your developers (and why would you do that?) in order to collect meaningful metrics. Off the top of my head, presuming you could come up with requirements so finely detailed that there was only a single way to develop them, you could perhaps use this as part of a job-applicant screening process -or- perhaps as part of the employee's annual review. But if the devs have to take a test as part of their annual review, I would think it only fair that the managers have to take a test as well, one designed by the developers. But as a production development measurement process, how would even a fairly "general" measurement be meaningful if during the measurement period, developer "A" mostly just added/repositioned/edited text fields with minimal workflow and developer "B" worked on a robust, non-ITSM, bespoke application? I would think you would also need a measurement system for (including, but not limited to): - The individual staff members contributing/defining requirements - The quality/completeness/ambiguity of the requirements gathered/documented - Any changes along the way - The over/under/confusion-injecting involvement of non-technical stake-holders and managers. Given those measurements, along with the developers metrics, I would think the outcome would quite often recommend reassigning the metrics seeking micro-manager(s) to somewhere they can't do as much damage... Now, I'm not an anti-management rebel as the above may suggest - I rely on and have worked with darned good managers and continue to do so today. However, over the years I've worked with lots of managers good and bad, both with my employers and customers. So when I hear someone say that they are looking for a way to measure development or capture development metrics, I don't see how you could get **meaningful** metrics simply because development efforts are rarely identical enough to compare one to the next fairly (individual scale or project scale). It strikes me as an exercise in futility -- or better yet, gathering metrics for the sake of gathering metrics. Again, as if the idea stems from a manager with far too much time on their hands who sees a new excel spreadsheet full of raw numbers like a Rubik's Cube: "something fun to fiddle with". My point of view on this stems from my personal experience where I've worked with folks who use the ITIL "measurement" philosophy as something to hide behind in order to measure waaaaaay too much just because they can and not necessarily because there is a clear *business-need*. I would wager that you would realize far better productivity, along with a substantial boost in morale, if you were to just get rid of the manager who suggested the idea in the first place. For if that manager seriously suggested this idea, who knows what other "great ideas" he has inflicted on the organization? Note: This is merely my stinky personal opinion -and- opinions will likely vary... -JDHood On Thu, Jun 5, 2014 at 4:31 AM, Theo Fondse <theo.fon...@gmail.com> wrote: > ** > > Hi Charlie! > > Although I have grown over the past few years to fully agree with LJ on > this subject, I can also understand the need for metrics to have something > to go by to know if our performance is on-par or not. > Sadly, measurements in the LOC style no longer give a true picture of > actual performance especially in terms of Remedy development. > The company I am currently working for has a 100% custom Remedy solution, > and are measuring performance based on number of requests closed per day > irrespective of workflow object count (but they include all types of > incidents, problems and change requests in this figure). > In my opinion, this is a better performance metric than pure LOC count, > but is also flawed because some types of requests are quicker and easier to > close than others. > > Shawn Pierson nailed it very well in his mail, if the purpose of the > exercise is to determine the "quality" of a Remedy developer or to guide > decisions around which questions your metrics should answer if you want > your company to keep the Remedy developer that will truly be most > beneficial to keep when the time comes to make those "hard decisions". > > Dave Shellman also pointed out the efficiency of code argument. > I would like to add to what he said by pointing out that the better Remedy > Developer will: > 1) Add config data to the system to configure it to do something rather > than write superfluous/duplicate code. > 2) Pre-allocate field ID's and share Filters/Active Links between > multiple forms. > These effectively lowers your LOC count and therefore LOC count does not > paint a true picture of quality or quantity of performance in such cases. > > Server and network infrastructure performance also plays a role in > developer performance. > If you are working on a server that takes 38 seconds just to open an > active link, you cannot be expected to churn hundreds of active links a > day. > > Anyone will be able to (intentionally or unintentionally) exploit > LOC-based metrics to their advantage by bloating their code, simply by: > 1) Adding a number of extra Filters or Active links in stead of making > something data configurable or generic. > 2) Copy-Pasting Filters or Active Links rather than pre-allocating > fieldID's and sharing workflow between forms. > 3) Writing bloat-up Filters/Active Links that only seem to be doing > something relevant, but has no consequence to the actual functionality. > > But, to answer your original question: > If the company insistence remains on measuring performance on an LOC > basis, and if > 1) You are guaranteed to always be presented with complete, clear, signed > off and sufficient requirement specification documentation, > 2) You are guaranteed to have access to properly performing > infrastructure (active link opens up in <3s), > 3) You are focussed on doing development and are not required to stop > what you are doing and attend to support issues, > 4) You do not attend more than 2 hours worth of meetings or workshops a > week, > 4) Complexity of the solution is low to medium, > 5) Good quality code is required. (As opposed to only evaluating if it > seems to be doing what was required), > 6) There are no external integrations to other systems where you do not > have full admin access and responsibility, > then my opinion is that, on an 8-hour working day, a good Remedy Developer > should be able to produce anywhere between 15 and 100 objects a day > counting a total combination of Forms, Active Links, Filters, Escalations, > Guides, Applications, Web Services, Menus, and Flashboards. > This is based on an approximate average of between ~5 to ~30 minutes time > spent on average per object. > > If a Remedy developer is creating more than an average of 100 objects a > day, then that developer is running the risk of probably not ensuring good > quality code, because he/she is: > 1) Copy-pasting code and not testing it the way it should be tested. > 2) Unwittingly creating a bloated monster of a system that is going to be > a costly nightmare to maintain. > In such cases, one could start looking at: > 1) Synchronising field ID's across al forms. > 2) Writing more generic code that can rather be shared and/or data-driven. > > HTH. > > Best Regards, > Theo > > > On Wed, Jun 4, 2014 at 4:41 PM, Charlie Lotridge <lotri...@mcs-sf.com> > wrote: > >> ** >> Hi all, >> >> Thanks for all your responses. And, while I didn't get quite what I was >> looking for, it's certainly my own fault for not starting with the more >> narrow question I eventually posed. And even that I should have qualified >> by stating "assuming perfectly efficient workflow". >> >> I fully agree with all of the positions that the quantity of workflow >> varies significantly with the quality of that workflow, the complexity of >> the requirements, and many other factors. I also agree that in isolation, >> "workflow object count" is a useless number. I *do* think that as part of >> a broader set of measurable characteristics it can be used to say something >> useful about the developer, hopefully to be used constructively. But this >> is a conversation that is diverging significantly from what I was looking >> for. >> >> LJ, it's unfortunate that the poker point data was so misunderstood and >> misused, but I can only imagine that it must have been quite satisfying to >> the team that drove that point home with the 1000x formula. >> >> I'll take you up on your offer to take this offline. It might take me a >> while to put something together that makes sense, but please expect >> something within a day or so. >> >> Thanks, >> Charlie >> >> >> On Wed, Jun 4, 2014 at 7:05 AM, LJ LongWing <lj.longw...@gmail.com> >> wrote: >> >>> ** >>> 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 <lotri...@mcs-sf.com> >>> 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 <lj.longw...@gmail.com> >>>> 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 <lotri...@mcs-sf.com> >>>>> 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_ >>>> >>> >>> _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"
