Re: Remedy Developer Performance Metrics
Hmmm... If the bugs could be traced to a given developers competency rather than due to conflicting or poor reqs and/or otherwise "unintended consequences of the reqs", you are likely on to something... But shouldn't we already be capturing something along those lines from the root causes identified in test-outputs and/or incident/problem/change mgmt? If it is reasonably clear that a given dev team member keeps causing avoidable problems, I would bet the entire dev team and their managers are painfully aware of it sooner or later, and probably well before the metrics would get around to pointing it out. So, you have a good point, but consider that accurate root-cause analysis and all the effort that entails is needed to "pin the tail" on the developer, rather than "something else". Also consider how often a seemingly simple requirement can result in two slight differently interpretations that are not recognized until a "defect" is registered due to an otherwise valid but inaccurate interpretation. For example, the interpretation of a stake-holder several levels removed from the dev and the dev who was handed a brief 6-bullet-point power-point presentation as the "requirement" (overly simplistic, but I've experienced that and worse - I'm likely not alone). In the end, I think regardless of how you measure development efforts, you will eventually have to figure out how to deal with the subjectivity that will likely be encountered when interpreting the metrics. Figure that out, and you may have a million dollar app!! For what it's worth, I believe you get the best results from growing your own dev's. Everyone has to start somewhere and (I think) pairing a new dev with an experienced, proven mentor on the team would be a far, far better investment of time & materials than trying to capture & interpret metrics based on tasks of varying comparability. That mentor would be in the best position to advise, guide and judge if there are show-stopping problems with the new dev. Note: This is merely my stinky personal opinion -and- opinions will likely vary... -JDHood On Thu, Jun 5, 2014 at 10:23 AM, Roney Samuel Varghese. wrote: > ** > A good start for metrics could be the number of bugs/issues raised against > a development effort and the number of occurrences of the same behavior > over a period of time. > > Regards, > Roney Samuel Varghese. > Sent from my iPhone > > On Jun 5, 2014, at 8:50 AM, JD Hood wrote: > > ** > 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 ide
Re: Remedy Developer Performance Metrics
Totally with you, JD! Rick On Thu, Jun 5, 2014 at 6:50 AM, JD Hood wrote: > ** > 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 waay 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 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
Re: Remedy Developer Performance Metrics
A good start for metrics could be the number of bugs/issues raised against a development effort and the number of occurrences of the same behavior over a period of time. Regards, Roney Samuel Varghese. Sent from my iPhone > On Jun 5, 2014, at 8:50 AM, JD Hood wrote: > > ** > 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 waay 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 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 com
Re: Remedy Developer Performance Metrics
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 waay 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 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
Re: Remedy Developer Performance Metrics
This discussion / argument is no different than what we dealt with in the 1980's. How do you measure Quality. During that time I headed up a software testing group that was working on automated testing (we actually built our own tool back in the days of (dare I mention it) DOS. We tried to measure things like LOC, etc, but the more highly skilled developers did things in less LOC than lower level folks. Then there's the conundrum of simple vs complex changes. The best we could come up with was the number of failures (as opposed to faults - refer to Boris Beizer on the difference between the two) and the cost incurred in correcting a failure that was released. The system was an extensively used PC based financial application used by as large number of clients. Then we developed a method (since the system communicated with our mainframe on a regular basis) to download patches rather than have our regional force have to visit the client and provide the updates. Cost went way down on the cost to correct which then skewed that metric. Basically this is a metric that has been struggled with since the inception of computers and seems to be a moving target based on the technology, complexity of the system and cost to correct issues. Kind of goes back to that Fast, Accurate, Cheap concept - if it's in house software vs a widely (ok so with the advent of 'cloud' this also has changed) - if the developer is a salaried employee vs a consultant (ie fixed cost or not) - how critical are the code changes from a data POV (ie the risk if something goes wrong) - kind of reminds me of my days of Cost Accounting in College - hurts to think about that stuff. When I was working on project plans for major releases I always had folks tell me that a developer can't estimate projects based on what they think it would take THEM to do (as most developers that build project plans are usually the more skilled folks) but what it would take an 'normal' person to do the task. I imagine the struggle will continue long past Remedy and technology as we know it. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Danny Kellett Sent: Thursday, June 5, 2014 4:55 AM To: arslist@ARSLIST.ORG Subject: Re: Remedy Developer Performance Metrics ** Quantity != Quality -- Danny Kellett dkell...@javasystemsolutions.com <mailto:dkell...@javasystemsolutions.com> On Thu, Jun 5, 2014, at 09:31 AM, Theo Fondse 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 an
Re: Remedy Developer Performance Metrics
" . Fast, Accurate, Cheap Pick two.." - Matt Black On Thu, Jun 5, 2014 at 10:55 AM, Danny Kellett < dkell...@javasystemsolutions.com> wrote: > ** > Quantity != Quality > > -- > Danny Kellett > dkell...@javasystemsolutions.com > > > > On Thu, Jun 5, 2014, at 09:31 AM, Theo Fondse 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 > 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 a
Re: Remedy Developer Performance Metrics
Quantity != Quality -- Danny Kellett dkell...@javasystemsolutions.com On Thu, Jun 5, 2014, at 09:31 AM, Theo Fondse 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 <[1]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
Re: Remedy Developer Performance Metrics
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 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 divergi
Re: Remedy Developer Performance Metrics
If what you are looking for is the old "Lines of Code" (LOC) measure used in the COCOMO Model and others, then I have always equated an Action Request System (ARS) object (Active Links, Active Link Guides, Filters, Filter Guides, Menus and Escalations - Not Forms) to 50 lines of code. I believe this is pretty close to the actual "C" which is generated. I don't count forms because this is like a DB Schema definition and not really code. However, if you want to include Forms, 100 lines of code per Form would probably be in the ballpark. Size of a project has always been a difficult estimation. If you just looking for a relative size to something else, I think lines of code would be the easiest with these simple units. Using my measures above. ITSM would be: Approximate Forms: 3000 -> 300,000 LOC Approximate Objects: 73,000 -> 3,650,000 LOC So ITSM is approximately 4 Million LOC which I believe is a Large Project in most models. On Tue, Jun 3, 2014 at 5:46 PM, Charlie Lotridge 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_ -- [image: Crab] Gordon M. Frank ITIL V3 Foundation Certified Security + Certified Mobile: 410-689-9373 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Remedy Developer Performance Metrics
>From seeing all the responses, I won't echo their thoughts or go into numbers such as # of objects created per day and all that. To look at it from a management point of view, I would try to measure the performance of Remedy devs the same as I would manage any other member of the IT staff. Are they working Incidents, Problems, Changes? Are they responsible for creating knowledge articles? I would look at the following metrics: 1. # of Successful vs. Failed changes where they are the Implementer 2. # of Resolved Incidents per time period 3. # of Re-opened Incidents per time period 4. # of changes implemented per time period 5. # of workarounds/ problem solutions found per time period 6. # of knowledge articles submitted 7. # of incidents that were not escalated Of course, I'm assuming that anything they are working on is based off of a request whether it be Incident/Change/Problem. Also, you can do a "360" evaluation where you survey their peers to see how they are doing (Many HR departments implement these types of evals these days). So while I'm sure this doesn't answer your question, I hope it offers a practical way of evaluating performance for the poor SOB that is getting an evaluation :) On Tue, Jun 3, 2014 at 5:46 PM, Charlie Lotridge 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_ -- *Tauf Chowdhury* ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Remedy Developer Performance Metrics
I’ll throw out the idea that another factor is whether the developer can find an OOB solution rather than code it (in the case of ITSM at least – custom apps are different), or to be ‘minimally invasive’ into OOB code and leverage what is already there. From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Charlie Lotridge Sent: Wednesday, June 4, 2014 10:42 AM To: arslist@ARSLIST.ORG Subject: Re: Remedy Developer Performance Metrics ** 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 mailto: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 variedif 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
Re: FW: Remedy Developer Performance Metrics
To me, Charlie seems like a PM type who, by his own admission doesn't understand how to measure development in Remedy. That's ok, no one else really can, either, except by results over a long period of time. To people like Charlie, who do an important job that I'm not trying to denigrate, there needs to be a separation between the "What" and the "How". The customer tells us What they need, the PM works with the developers and customer to come up with a combination of scope and schedule that works for them all, but the How needs to be the domain of the developer/architects. When people who don't understand a technology try to insert themselves into it, it slows the process and almost cannot improve the results. Leave engineering to the engineers, and measure the results more than the process. Rick On Wed, Jun 4, 2014 at 8:10 AM, Jim Coryat (jcoryat) wrote: > ** > > Ok, I agree more with LJ than Charlie, but I see both sides. > > > > Personally having been a software engineer for many years. It really > depends on what you are trying to discern. While this is a discrete > discipline, you can measure the overall project progress and estimated > completion timeline to give you a rough approximation of performance. I > have worked with project managers in the past in generating estimates of > effort based on the number of artifacts within a system that will need to > be changed and estimates of effort for each etc. You could roughly derive > a metric from that. However that does not take into effect when > complications arise and do not fit into the paradigm, which will reflect > poorly in the metric. There is no replacement for knowing the subject > matter and being able to communicate with your team on performance. > > > > I can churn out objects by the gross, however the quality delivered may be > another thing. My point is don’t get caught up in the counts as your > measurement, use it as one of several metrics which will give you a more > accurate interpretation. > > > > Jim Coryat > > x34655 > > > > *From:* Charlie Lotridge [mailto:lotri...@mcs-sf.com] > *Sent:* Tuesday, June 03, 2014 7:01 PM > *Subject:* Re: Remedy Developer Performance Metrics > > > > ** > > Dave, > > > > Ok, fair enough. And I agree there are a lot of > qualifications/considerations. > > > > I'm seeing now, though, that I posed too broad (and sensitive) a question. > Let me try a different angle on this, which should be sufficient for my > needs: > > > > On a good day, and if it's all you had to do, about how many workflow > objects (AL's, filters, escalations) can you create (minimum, maximum, and > average)? > > > > For me, if it's very complex workflow, it might be as low as 15-20 objects. > > > > On the other hand, if it's a highly mechanical operation - e.g. I need to > replicate the same On Return active link that perhaps calls a common guide > across all the fields of several forms, so I'm only changing the field id > and doing a "Save As" - it might get up to a few hundred (say one/minute). > But even on my worst day and the most complex workflow it's not going to > be just one object on the low end, and it's never going to be a thousand on > the high end. > > > > So for me, min to max, my answer would be 15 to, say, 400. And, on > average, I'd say it's probably around 30 or so. > > > > So, anyone willing to answer, I'd appreciate the data points. > > > > Thanks, > Charlie > > > > On Tue, Jun 3, 2014 at 4:44 PM, Shellman, David > wrote: > > Charlie, > > Being an AR System admin is not about how many active links or filters or > fields one can put together in a day. Do they work as intended? Are the > permissions right? If they are not working as intended how well does the > individual do to figure out what is not right and correct the problem. Is > it entirely new workflow or is the individual adding to something another > person put together? Or they finding and correcting issues and with > existing workflow. > > If you count workflow objects one could do coding to meet that criteria. > On the other had they could be efficient and combine three actions into one > filter instead of three. > > Finally there is more than one way to create code within the AR System. > One individual could do something one way and another individual > completely different. Both ways meet the design requirements. > > Dave > > > On Jun 3, 2014, at 5:46 PM, "Charlie Lotridge" > wrote: > > > > ** > > > Hi all, > > > > I'm
FW: Remedy Developer Performance Metrics
Ok, I agree more with LJ than Charlie, but I see both sides. Personally having been a software engineer for many years. It really depends on what you are trying to discern. While this is a discrete discipline, you can measure the overall project progress and estimated completion timeline to give you a rough approximation of performance. I have worked with project managers in the past in generating estimates of effort based on the number of artifacts within a system that will need to be changed and estimates of effort for each etc. You could roughly derive a metric from that. However that does not take into effect when complications arise and do not fit into the paradigm, which will reflect poorly in the metric. There is no replacement for knowing the subject matter and being able to communicate with your team on performance. I can churn out objects by the gross, however the quality delivered may be another thing. My point is don’t get caught up in the counts as your measurement, use it as one of several metrics which will give you a more accurate interpretation. Jim Coryat x34655 From: Charlie Lotridge [mailto:lotri...@mcs-sf.com] Sent: Tuesday, June 03, 2014 7:01 PM Subject: Re: Remedy Developer Performance Metrics ** Dave, Ok, fair enough. And I agree there are a lot of qualifications/considerations. I'm seeing now, though, that I posed too broad (and sensitive) a question. Let me try a different angle on this, which should be sufficient for my needs: On a good day, and if it's all you had to do, about how many workflow objects (AL's, filters, escalations) can you create (minimum, maximum, and average)? For me, if it's very complex workflow, it might be as low as 15-20 objects. On the other hand, if it's a highly mechanical operation - e.g. I need to replicate the same On Return active link that perhaps calls a common guide across all the fields of several forms, so I'm only changing the field id and doing a "Save As" - it might get up to a few hundred (say one/minute). But even on my worst day and the most complex workflow it's not going to be just one object on the low end, and it's never going to be a thousand on the high end. So for me, min to max, my answer would be 15 to, say, 400. And, on average, I'd say it's probably around 30 or so. So, anyone willing to answer, I'd appreciate the data points. Thanks, Charlie On Tue, Jun 3, 2014 at 4:44 PM, Shellman, David mailto:dave.shell...@te.com>> wrote: Charlie, Being an AR System admin is not about how many active links or filters or fields one can put together in a day. Do they work as intended? Are the permissions right? If they are not working as intended how well does the individual do to figure out what is not right and correct the problem. Is it entirely new workflow or is the individual adding to something another person put together? Or they finding and correcting issues and with existing workflow. If you count workflow objects one could do coding to meet that criteria. On the other had they could be efficient and combine three actions into one filter instead of three. Finally there is more than one way to create code within the AR System. One individual could do something one way and another individual completely different. Both ways meet the design requirements. Dave > On Jun 3, 2014, at 5:46 PM, "Charlie Lotridge" > mailto: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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "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"
Re: Remedy Developer Performance Metrics
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 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 variedif 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 out400 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.
Re: Remedy Developer Performance Metrics
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 variedif 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 out400 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 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 dev
Re: Remedy Developer Performance Metrics
What about equivalent metrics in creating objects but diffences in debugging? Requester interaction? Complexity of requirements? Meeting time deadlines? Playing golf with the IT director? From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Charlie Lotridge Sent: Tuesday, June 03, 2014 9:01 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy Developer Performance Metrics ** Dave, Ok, fair enough. And I agree there are a lot of qualifications/considerations. I'm seeing now, though, that I posed too broad (and sensitive) a question. Let me try a different angle on this, which should be sufficient for my needs: On a good day, and if it's all you had to do, about how many workflow objects (AL's, filters, escalations) can you create (minimum, maximum, and average)? For me, if it's very complex workflow, it might be as low as 15-20 objects. On the other hand, if it's a highly mechanical operation - e.g. I need to replicate the same On Return active link that perhaps calls a common guide across all the fields of several forms, so I'm only changing the field id and doing a "Save As" - it might get up to a few hundred (say one/minute). But even on my worst day and the most complex workflow it's not going to be just one object on the low end, and it's never going to be a thousand on the high end. So for me, min to max, my answer would be 15 to, say, 400. And, on average, I'd say it's probably around 30 or so. So, anyone willing to answer, I'd appreciate the data points. Thanks, Charlie On Tue, Jun 3, 2014 at 4:44 PM, Shellman, David mailto:dave.shell...@te.com>> wrote: Charlie, Being an AR System admin is not about how many active links or filters or fields one can put together in a day. Do they work as intended? Are the permissions right? If they are not working as intended how well does the individual do to figure out what is not right and correct the problem. Is it entirely new workflow or is the individual adding to something another person put together? Or they finding and correcting issues and with existing workflow. If you count workflow objects one could do coding to meet that criteria. On the other had they could be efficient and combine three actions into one filter instead of three. Finally there is more than one way to create code within the AR System. One individual could do something one way and another individual completely different. Both ways meet the design requirements. Dave > On Jun 3, 2014, at 5:46 PM, "Charlie Lotridge" > mailto: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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org<http://www.arslist.org> "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ Portions of this message may be confidential under an exemption to Ohio's public records law or under a legal privilege. If you have received this message in error or due to an unauthorized transmission or interception, please delete all copies from your system without disclosing, copying, or transmitting this message. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Remedy Developer Performance Metrics
I had a similar experience. The customer requested a change to an out of the box solution and another Remedy Developer thought they would "dazzle" the customer with some extremely bloated, overly complicated solution. The customer hated it, it was a nightmare to maintain (and understand) and took about 2 months to develop. They eventually rejected it. About a week later I came back with a very simple solution (1 extra form, and a couple of active links) and it's been approved and will be moving over to production. So the solution that the other developer was creative and did a lot more than the customer requested, but does that make them a better developer if it eventually is not what the customer wanted? Lisa -Original Message- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: Wednesday, June 04, 2014 8:43 AM To: arslist@ARSLIST.ORG Subject: Re: Remedy Developer Performance Metrics Hi, I once got the assignment to add some functionality the ITSM notification system. I could probably have hammered away right away, adding a bunch of field and loads of FLTR/ACTL/ESCL to do this. Maintaining that solution would have been a nightmare. Instead I sat staring at the existing code for a week, and finally I added one FIELD and one FLTR, and then changed one FIELD and one FLTR. These were 4 very expensive workflow objects! Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > Dave, > > Ok, fair enough. And I agree there are a lot of > qualifications/considerations. > > I'm seeing now, though, that I posed too broad (and sensitive) a question. > Let me try a different angle on this, which should be sufficient for > my > needs: > > On a good day, and if it's all you had to do, about how many workflow > objects (AL's, filters, escalations) can you create (minimum, maximum, > and average)? > > For me, if it's very complex workflow, it might be as low as 15-20 objects. > > On the other hand, if it's a highly mechanical operation - e.g. I need > to replicate the same On Return active link that perhaps calls a > common guide across all the fields of several forms, so I'm only > changing the field id and doing a "Save As" - it might get up to a few > hundred (say one/minute). > But even on my worst day and the most complex workflow it's not going > to be just one object on the low end, and it's never going to be a > thousand on the high end. > > So for me, min to max, my answer would be 15 to, say, 400. And, on > average, I'd say it's probably around 30 or so. > > So, anyone willing to answer, I'd appreciate the data points. > > Thanks, > Charlie > > > On Tue, Jun 3, 2014 at 4:44 PM, Shellman, David > wrote: > >> Charlie, >> >> Being an AR System admin is not about how many active links or >> filters or fields one can put together in a day. Do they work as >> intended? Are the permissions right? If they are not working as >> intended how well does the individual do to figure out what is not >> right and correct the problem. Is it entirely new workflow or is the >> individual adding to something another person put together? Or they >> finding and correcting issues and with existing workflow. >> >> If you count workflow objects one could do coding to meet that criteria. >> On the other had they could be efficient and combine three actions >> into one filter instead of three. >> >> Finally there is more than one way to create code within the AR System. >> One individual could do something one way and another individual >> completely different. Both ways meet the design requirements. >> >> Dave >> >> > On Jun 3, 2014, at 5:46 PM, "Charlie Lotridge" >> > >> 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 &g
Re: Remedy Developer Performance Metrics
Hi, I once got the assignment to add some functionality the ITSM notification system. I could probably have hammered away right away, adding a bunch of field and loads of FLTR/ACTL/ESCL to do this. Maintaining that solution would have been a nightmare. Instead I sat staring at the existing code for a week, and finally I added one FIELD and one FLTR, and then changed one FIELD and one FLTR. These were 4 very expensive workflow objects! Best Regards - Misi, RRR AB, http://www.rrr.se (ARSList MVP 2011) Ask the Remedy Licensing Experts (Best R.O.I. Award at WWRUG10/11/12/13): * RRR|License - Not enough Remedy licenses? Save money by optimizing. * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs. Find these products, and many free tools and utilities, at http://rrr.se. > Dave, > > Ok, fair enough. And I agree there are a lot of > qualifications/considerations. > > I'm seeing now, though, that I posed too broad (and sensitive) a question. > Let me try a different angle on this, which should be sufficient for my > needs: > > On a good day, and if it's all you had to do, about how many workflow > objects (AL's, filters, escalations) can you create (minimum, maximum, and > average)? > > For me, if it's very complex workflow, it might be as low as 15-20 objects. > > On the other hand, if it's a highly mechanical operation - e.g. I need to > replicate the same On Return active link that perhaps calls a common guide > across all the fields of several forms, so I'm only changing the field id > and doing a "Save As" - it might get up to a few hundred (say one/minute). > But even on my worst day and the most complex workflow it's not going to > be just one object on the low end, and it's never going to be a thousand on > the high end. > > So for me, min to max, my answer would be 15 to, say, 400. And, on > average, I'd say it's probably around 30 or so. > > So, anyone willing to answer, I'd appreciate the data points. > > Thanks, > Charlie > > > On Tue, Jun 3, 2014 at 4:44 PM, Shellman, David > wrote: > >> Charlie, >> >> Being an AR System admin is not about how many active links or filters or >> fields one can put together in a day. Do they work as intended? Are the >> permissions right? If they are not working as intended how well does the >> individual do to figure out what is not right and correct the problem. Is >> it entirely new workflow or is the individual adding to something another >> person put together? Or they finding and correcting issues and with >> existing workflow. >> >> If you count workflow objects one could do coding to meet that criteria. >> On the other had they could be efficient and combine three actions into one >> filter instead of three. >> >> Finally there is more than one way to create code within the AR System. >> One individual could do something one way and another individual >> completely different. Both ways meet the design requirements. >> >> Dave >> >> > On Jun 3, 2014, at 5:46 PM, "Charlie Lotridge" >> 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_ >> >> >> ___ >> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org >> "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" > ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Remedy Developer Performance Metrics
It’s been a really long time where I worked in a shop where you can assume that 1) you have completed requirements, 2) that you can do only development work, and 3) it’s entirely a custom application. This seems to be fairly rare in our world of ITSM. I can say that with out of the box applications, you spend maybe 75% or more of your time reverse engineering BMC’s code and of the 25% or less left, you spend your time designing and implementing your stuff. That’s also rare though because it seems like almost nobody gets to be a pure Remedy developer anymore. Also, Remedy is going to be different than lines of code in a significant way. Let’s say I have a requirement to add a new field to Work Info on Incidents, a flag where you mark something as confidential where only the currently assigned group can see it. It’s going to be a decent amount of work at the end of the day, because I’ll have to add the field as a display only field on the HPD:Help Desk form (0 new workflow objects), add a field with that flag to the HPD Work Info form (0 new workflow objects), set up row-level access on the form (0 new workflow objects), then I get around to writing code, which would be probably 2 or 3 filters created at best. However, I’d have to update the filter that writes to Work Info on Incident save, I’d have to update the push fields on the Active Link on the “Add” button, and probably several other areas of workflow. To make sure this works, I’d have to potentially update several other pieces of workflow that wouldn’t be understood without lots of running of log files and such. Now when you’re dealing with custom applications, especially if you’re not the one who built it, one of the problems with Remedy is that there are a lot of people who either don’t have a development background and got pushed into Remedy, or they have a programming background and got pushed into Remedy. The former results in illogical, badly designed Remedy code. The latter results in a lot of external calls to code written in the development platform of their choice. When you have teams of people, you get a mix of this. So at the end of the day, I agree with you that it’s not a simple matter of judging metrics as if Remedy development was factory work. Only a Remedy developer can judge another Remedy developer on a “coding” basis. Here’s a few things I would look for: · Is this person using Active Links where he should be using Filters? · Is he making his workflow generic enough where it can be used for more than one thing (if applicable), especially making it data driven to prevent the need for hardcoding things? · Does it flow straight-forward enough that someone else can understand it? · Most importantly, is this person getting the business requirements handed to him or her done in a reasonable timeframe in a supportable manner? I don’t want to totally compare Remedy development to an art form but look at it this way. If you start paying a painter by the number of paintings he’s commissioned for, you’re going to end up wasting thousands of dollars on canvas with just a streak of a single color of paint splattered on it. Conversely, maybe you don’t need the next Mona Lisa so you don’t want a painter who is so talented that he gets bogged down in the perfectionism. Finding the balance between the two with the real metric being, “Is this developer meeting the user’s need?” is really the only valid thing to judge a developer by. Thanks, Shawn Pierson Remedy Developer | Energy Transfer From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Charlie Lotridge Sent: Tuesday, June 03, 2014 4:47 PM To: arslist@ARSLIST.ORG Subject: Remedy Developer Performance Metrics ** 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_ Private and confidential as detailed here: http://www.energytransfer.com/mail_disclaimer.aspx . If you cannot access the link, please e-mail sender. ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Remedy Developer Performance Metrics
Folks, This reminds me of the story of IBM hiring Microsoft to develop an OS for what became ‘personal computers’. Big Blue wanted to pay MS for the new OS based upon the number of lines of code delivered. MS (Bill?) said that 3 three elegant lines of code should be worth the same, or more, than the same function done in 100 lines. IBM insisted on their metric, and that, my friends is how “PC-DOS” became (begat?) “MS-DOS”. I suggest that the proper metrics for developers would be: 1. Does it work? Precisely measured with ‘testing’ 2. Was it delivered on time? Easily measured with a calendar (or stopwatch) 3. Was it delivered within budget? Might require a spreadsheet IMHO, the number of ARS objects, lines of code, characters in a document, or the angle of the sun - all fail to identify the important metrics. HTH, Joel Joel Senderjdsen...@earthlink.net310.829.5552 From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Charlie Lotridge Sent: Tuesday, June 03, 2014 6:01 PM To: arslist@ARSLIST.ORG Subject: Re: Remedy Developer Performance Metrics ** Dave, Ok, fair enough. And I agree there are a lot of qualifications/considerations. I'm seeing now, though, that I posed too broad (and sensitive) a question. Let me try a different angle on this, which should be sufficient for my needs: On a good day, and if it's all you had to do, about how many workflow objects (AL's, filters, escalations) can you create (minimum, maximum, and average)? For me, if it's very complex workflow, it might be as low as 15-20 objects. On the other hand, if it's a highly mechanical operation - e.g. I need to replicate the same On Return active link that perhaps calls a common guide across all the fields of several forms, so I'm only changing the field id and doing a "Save As" - it might get up to a few hundred (say one/minute). But even on my worst day and the most complex workflow it's not going to be just one object on the low end, and it's never going to be a thousand on the high end. So for me, min to max, my answer would be 15 to, say, 400. And, on average, I'd say it's probably around 30 or so. So, anyone willing to answer, I'd appreciate the data points. Thanks, Charlie On Tue, Jun 3, 2014 at 4:44 PM, Shellman, David wrote: Charlie, Being an AR System admin is not about how many active links or filters or fields one can put together in a day. Do they work as intended? Are the permissions right? If they are not working as intended how well does the individual do to figure out what is not right and correct the problem. Is it entirely new workflow or is the individual adding to something another person put together? Or they finding and correcting issues and with existing workflow. If you count workflow objects one could do coding to meet that criteria. On the other had they could be efficient and combine three actions into one filter instead of three. Finally there is more than one way to create code within the AR System. One individual could do something one way and another individual completely different. Both ways meet the design requirements. Dave > On Jun 3, 2014, at 5:46 PM, "Charlie Lotridge" 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years" _ARSlist: "Where the Answers Are" and have been for 20 years_ --- This email is free from viruses and malware because avast! Antivirus protection is active. http://www.avast.com ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Remedy Developer Performance Metrics
Dave, Ok, fair enough. And I agree there are a lot of qualifications/considerations. I'm seeing now, though, that I posed too broad (and sensitive) a question. Let me try a different angle on this, which should be sufficient for my needs: On a good day, and if it's all you had to do, about how many workflow objects (AL's, filters, escalations) can you create (minimum, maximum, and average)? For me, if it's very complex workflow, it might be as low as 15-20 objects. On the other hand, if it's a highly mechanical operation - e.g. I need to replicate the same On Return active link that perhaps calls a common guide across all the fields of several forms, so I'm only changing the field id and doing a "Save As" - it might get up to a few hundred (say one/minute). But even on my worst day and the most complex workflow it's not going to be just one object on the low end, and it's never going to be a thousand on the high end. So for me, min to max, my answer would be 15 to, say, 400. And, on average, I'd say it's probably around 30 or so. So, anyone willing to answer, I'd appreciate the data points. Thanks, Charlie On Tue, Jun 3, 2014 at 4:44 PM, Shellman, David wrote: > Charlie, > > Being an AR System admin is not about how many active links or filters or > fields one can put together in a day. Do they work as intended? Are the > permissions right? If they are not working as intended how well does the > individual do to figure out what is not right and correct the problem. Is > it entirely new workflow or is the individual adding to something another > person put together? Or they finding and correcting issues and with > existing workflow. > > If you count workflow objects one could do coding to meet that criteria. > On the other had they could be efficient and combine three actions into one > filter instead of three. > > Finally there is more than one way to create code within the AR System. > One individual could do something one way and another individual > completely different. Both ways meet the design requirements. > > Dave > > > On Jun 3, 2014, at 5:46 PM, "Charlie Lotridge" > 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_ > > > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > "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"
Re: Remedy Developer Performance Metrics
Charlie, Being an AR System admin is not about how many active links or filters or fields one can put together in a day. Do they work as intended? Are the permissions right? If they are not working as intended how well does the individual do to figure out what is not right and correct the problem. Is it entirely new workflow or is the individual adding to something another person put together? Or they finding and correcting issues and with existing workflow. If you count workflow objects one could do coding to meet that criteria. On the other had they could be efficient and combine three actions into one filter instead of three. Finally there is more than one way to create code within the AR System. One individual could do something one way and another individual completely different. Both ways meet the design requirements. Dave > On Jun 3, 2014, at 5:46 PM, "Charlie Lotridge" 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Remedy Developer Performance Metrics
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" 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 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 >> 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"
Re: Remedy Developer Performance Metrics
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 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 > 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Re: Remedy Developer Performance Metrics
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 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_ ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
Remedy Developer Performance Metrics
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 ___ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
