RE: programmer productivity. -- MIDRANGE-L

Brad Stone wrote:

>> Wouldn't that be so they can see if they're getting their 
>> money's worth?  
>
>I've stayed out of this thread until now.  But this kind of 
>statement sort of irks me.  

Sorry.  Like I said, it's a subject which is very controversial.

>Because some folks don't understand what we 
>do (and only use buzzwords because they think 
>it makes them sound intelligent) they want us to 
>try and come up with some way of measuring 
>how much we work.

Oh, I agree that the non-technical people are trying to simplify what we do
so they can put the results in a spreadsheet and say that "Brad is a better
programmer then Buck because he produces 5 web pages per day."  A simple
answer to a complex question.

>Look at the end product.  Is it good?  Great.  
>Does it suck?  Time to do some reasearch/
>reorganization.

In Utopia, the process of solving business problems goes through several
steps: Identify the problem (opportunity?), Design a solution, code a
solution, deploy the solution.  One set of metrics can hardly be used for
each of the phases.  I think (I hope!) that the accountants don't want a
hard metric on anything besides "code a solution."  That's the programmer's
job.  Now, in most midrange-using companies, one person (me) acts as
designer, coder and implementer.  I believe that coding and implementation
can be roughly measured.

>When I go to bring my motorcycle to my 
>mechanic for work, sure I'm intrigued because 
>it amazes me how he adjusts the valves or 
>tunes my carburators to perfection, squeezing 
>out 2 more hp.  But, do I question him on his work
>habits or how many carbs a day he does?  No.  

But his boss does.  If the mechanic spends 20 hours working on my 1943
Indian because "it's cool" and ignores the other work, shouldn't the boss
care?  What if the other mechanic in the garage can do the same work on my
Indian AND handle the other bikes too?  Don't we agree that the second
mechanic is more efficient, or more productive?

>Not much different here.  Trying to measure 
>intangibles is silly.

Yes!  It is silly.  The point is to try to measure the measurable, and
however poor, even lines of code is a better judge than none at all.  At
least it is a hard number... not a great number, but it can be verified by
independent analysis.

>Evaluating the end product is what matters.  

Doesn't this depend on the problem and the design?  I would assume that any
professional programmer can code "to specification."  You've been designing,
coding and implementing some new, cool Web based stuff, so you *have* an
"end product."  Those of us living in maintenance h e l l (gotta get past
the censors! <G>) don't have a product, as much as a known bug to be
removed.  Typically only a few lines of code are affected, but if I got
measured on the number of bugs that got into production _from the code that
I affected_ then I would be a very happy man indeed!

>But of course, until we start rewarding extra effort 
>and hard work not many will have or keep the 
>gumption that made them stars to their peers.  
>That's another story altogether.

Another point of agreement!  That's why it's vital to measure _what's
important_.  If we measured LOC, then you can bet that programmers will
simply write more lines of code to get the job done.  A more interesting
measurement is number of edit/compile cycles to complete the project.  Sort
of makes you think before compiling.  And isn't it the thinking part we want
to reward?

Good post, and sorry I irked you.

Buck Calabro
Aptis; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.midrange.com
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---