Re: Remedy Developer Performance Metrics

2014-06-05 Thread JD Hood
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

2014-06-05 Thread Rick Cook
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

2014-06-05 Thread Roney Samuel Varghese.
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

2014-06-05 Thread JD Hood
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

2014-06-05 Thread Ken Pritchard
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

2014-06-05 Thread Theo Fondse
" . 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

2014-06-05 Thread Danny Kellett
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

2014-06-05 Thread Theo Fondse
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

2014-06-04 Thread Gordon Frank
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

2014-06-04 Thread Tauf Chowdhury
>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

2014-06-04 Thread Ken Pritchard
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

2014-06-04 Thread Rick Cook
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

2014-06-04 Thread Jim Coryat (jcoryat)
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

2014-06-04 Thread Charlie Lotridge
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

2014-06-04 Thread LJ LongWing
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

2014-06-04 Thread richard....@bwc.state.oh.us
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

2014-06-04 Thread Kemes, Lisa A DLA CTR INFORMATION OPERATIONS
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

2014-06-04 Thread Misi Mladoniczky
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

2014-06-04 Thread Pierson, Shawn
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

2014-06-03 Thread Joel Sender
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

2014-06-03 Thread Charlie Lotridge
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

2014-06-03 Thread Shellman, David
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

2014-06-03 Thread Rick Cook
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

2014-06-03 Thread Charlie Lotridge
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

2014-06-03 Thread LJ LongWing
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

2014-06-03 Thread Charlie Lotridge
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"