RE: RE: programmer productivity.

[Evan Harris <spanner@xxxxxxxxxx>]

Hi Mike

I hope that you took my reply as being somewhat tongue in cheek also:) I 
take your point about the uncertainty of programming - is it science or is 
it art ? but that argument probably reflects the reality of anything that 
involves intellectual effort.

What I mean by this is that amost anything that is done really 
exceptionally well can be considered "art" to the initiated if it far 
exceeds the normal expectations or standards.  Even simple programming is 
still "magic" to many people.

To qualify the vast majority of commercial code as art would be a hard case 
to argue. I'm not necessarily proposing lines of code as a measure, which 
is why a number of times I alluded to developing measures appropriate to 
your shop. Maybe you want function points delivered, maybe you want a user 
satisfaction survey, requests delivered, bug reduction, whatever.

The point is, as creative, smart individuals we should be able to come up 
with a measure that measures what we believe we deliver to whatever 
business we are servicing. Once it's agreed then we can demonstrate our 
value. If we don't demonstrate our value, then from a business perspective 
we have none (I know this is a deliberate exaggeration, but I'm sure you 
get my drift !)

At the risk of repeating myself the discussions and comments that dismiss 
the desire to measure the performance of what are (when it all comes down 
to it) paid professionals are utterly mistaken. Me, I'd be jumping on that 
measurement bandwagon and making sure I get a measure I am happy with and 
can live with and even better - exceed on a regular basis.

No measure is perfect, so I'd probably look for two or three measures I can 
provide every month that would provide an indicator of performance along a 
couple of lines of reference.

I realise this is a technical list (that's why I subscribe) but I think us 
technical types have to learn to tango with the management boys and that 
means speaking in the terms they understand and delivering on the kinds of 
things business expect to see when they have dollars invested. Maybe that's 
why we see so many NT  boxes getting wheeled in around the traps.....

Regards
Evan Harris

>I like these little debates. Far more interesting than finding out how the 
>3rd parameter in the QXYZLMN API works, or "HELP!! URGENT!! I compiled my 
>program and it failed. Can anybody tell me what I've done wrong?".
>
>The point about the painter was a bit tongue in cheek, and simply 
>reflected the uncertainty of programming - is it a science or is it an 
>art? If it's a science then metrics could and should be used. If it's an 
>art, then metrics are ridiculous. Most places I've worked do not have the 
>concept of a programmer as such. Perhaps I'm lucky, but most places I've 
>been in in my working life have simply lumped the role into the 
>analyst/programmer bucket. I once worked on an Arthur Andersen run project 
>and they had the concept of coders who only coded. In those circumstances 
>it might be useful to count lines of code, but then I'd argue that a 
>program with 100 conditionals and 100 sequential statements is of a more 
>complex nature than one of 200 sequential statements.
>
>The argument about science or art is as old as the profession. The ability 
>to conceptualize logic in your mind is an art. The ability to code syntax 
>is the science. How do you measure the former?
>
>By the way I don't believe these discussions should take place unless it's 
>6pm on a Friday night and the company bar has opened, and somebody has 
>dialled for pizza.
>-----Original Message-----  From:   Evan Harris 
>[<mailto:spanner@ihug.co.nz>mailto:spanner@ihug.co.nz]  Sent:   Tuesday, 
>14 November 2000 
>17:15  To:     MIDRANGE-L@midrange.com  Subject:        RE: RE: programmer 
>productivity.
>
>Mike
>
>I've stayed out of this so far, but finally couldn't help myself.
>
>With all due respect (and I hope I don't hurt anyone's feelings here 
>:))  the vast majority of programmers in the world do NOT fall into 
>the  Michaelangelo school of programming. To draw out your painting 
>analogy  there are a frightening number who I would not let paint my fence 
>let alone  my portrait.
>
>I honestly can't see the problem with being measured. All the people I 
>have  ever worked with who are any good have never had any problem with 
>meeting  any measure at any place they wanted to work.
>
>Accountants actually have plenty of measures in terms of their 
>quantifying  their performance. Not that I'm an accountant or pro 
>accountant in terms of  this argument. I just happen to have seen the 
>deadlines and measures  accountants in good companies have to work to. 
>They are numbers people and  like to quantify things therefore they want a 
>measure on programmer  productivity. A good IT department ought to be able 
>to create a measure  that meets the needs of the business and demonstrates 
>their value.
>
>An IT department that can't come up with such a measure can hardly play 
>the  creative card IMHO. :)
>
>You might find that if you could produce some measures that are relevant 
>to  your shop that you have better access to the  budget instead of 
>watching  the marketing people (who produce any amount of measures at 
>any  opportunity) take budget dollars you could use.
>
>It is in any shops interest to find a measure relevant to their business 
>as  it helps them justify their portion of the company's budget.This is 
>just  plain good business. You just might find that a good productivity 
>measure  proves you do a good job to the rest of the company rather than 
>having that  "justifying your existence to the doubters" feeling.
>
>Thats my take, anyway.
>
>Regards  Evan Harris
>
> >Measuring productivity by lines of code is like measuring an artists 
> work  >by the number of brush strokes applied to the canvas.  >  >There 
> is no measurement other than by your peers. Ask yourself.....would  >you 
> work on another project with Joe Source,  Mary Code?  >  >A small 
> analogy. Last century, Dickens was paid by the word for his  >novels. His 
> novels were printed in newspapers as weekly instalments. Read  >a 18th 
> century newspaper to get an idea of the more is better syndrome.  >  >A 
> long, long time ago in a place far away the concept of elegance was 
> a  >measure of an algorithms efficiency. It's the difference between 
> a  >massively powerful computer churning through the possibilities and 
> not  >being able to beat the human mind in a game of 
> chess.  >-----Original Message-----  From:   alan 
> shore 
 >  >[<<mailto:SHOREA@dime.com>mailto:SHOREA@dime.com>mailto:SHOREA@dime.com 
> ]  Sent:   Saturday, 11  >November 2000 
> 2:15  To:     MIDRANGE-L@midrange.com  Subject:        Re:  >RE: 
> programmer productivity.  >  >I hope I understand what you are writing 
> here, otherwise I am definitley  >showiwing what an idiot I am.  I 
> completely disagree. Lines of Code is  >probably THE worst way of 
> charting someones performance. Granted RPG  >(as-of-now, anyway) is of a 
> fixed format. But what about free-format RPG,  >free-format COBOL, 
> free-format UNIX etc. etc.. One mans line of code  >becomes another mans 
> 4/5 lines of code. Does this mean that programmer B  >is 4/5 times more 
> productive than programmer A. The responses of go back  >to the 
> bean-counters and ask what they use to measure their productivity  >has 
> to be the best answer.  I am curious as to what reply was 
> received.  >Plus, ask them why do they want to measure a programmers 
> productivity  >anyway. >>> "Richard Jackson" 
> <richardjackson@richardjackson.net> 11/10  >9:04 AM >>>  About 15 years 
> ago, I spent a bunch of time looking at this  >problem.  I also  did a 
> presentation at Common about it.  At that time, no  >system 
> of  measurement produced better fidelity than lines of code  >(LOC).  LOC 
> is  flawed because its scope is narrow and its definition  >contains 
> serious  flaws.  In order to heal the definition problem, one  >must 
> account for the  effect of complexity on LOC.  >  >Richard 
> Jackson  Richard Jackson and Associates Ltd.  IBM 
> Business  >Partner 
 >  
 >><<mailto:richardjackson@richardjackson.net>mailto:richardjackson@richardjackson.net>mailto:richardjackson@richardjackson.net
 > 
 >  ><http://www.richardjacksonltd.com>http://www.richardjacksonltd.com 
> Telephone: 1 (303) 808-8058  >  >-|-----Original 
> Message-----  -|From:  >owner-midrange-l@midrange.com 
 >  
 >>-|[<<mailto:owner-midrange-l@midrange.com>mailto:owner-midrange-l@midrange.com>mailto:owner-midrange-l@midrange.com]On
 > 
 >  >Behalf Of Gary R. Patterson  -|Sent: Friday, November 10, 2000 
> 2:36  >AM  -|To: MIDRANGE-L@midrange.com  -|Subject: RE: 
> programmer  >productivity.  -|  -|  -|Lots of ways to measure 
> programmer  >productivity.  A few ideas:  -|  -|Developers: Lines of code 
> vs. defects  >in produced code.  -|Developers: Performance to project 
> timelines vs.  >defects.  -|Developers: Performance to task estimate vs. 
> defects.  Really  >needs  -|standardized estimates.  -|Maintenance 
> programmers:  Number of  >fixes (weighted for complexity) vs.  -|defects 
> in fixed  >code.  -|  -|Subjective measurements, too: Code review, 
> standards  >compliance, peer and  -|supervisor performance 
> evaluation.  -|  -|Of  >course, you have to measure non-coding tasks, 
> too.  Some of the  >above  -|metrics apply.  -|  -|1) Start tracking 
> defects, and charge them  >to the responsible  -|individual 
> or  -|team.  (Have security walk you to  >the car for the first week or 
> two.)  -|2) Implement detailed time  >reporting.  (Watch out for mail 
> that ticks.)  -|3) Implement code reviews  >(good idea anyway).  Standard 
> criteria, rotating  -|responsibility.  Check  >for standards 
> compliance.  (This way you  -|can share a  -|little of the  >heat with 
> your senior staff.)  -|4) Implement an estimating  >methodology.  (Big 
> fun.  Nothing like a rousing  -|afternoon of  >function-point 
> counting.)  -|5) Start tracking performance to estimate and  >performance 
> to timeline.  -|(Avoid food and beverages that are not  >prepared in your 
> presence.)  -|  -|Enjoy.  Might actually even improve  >productivity and 
> quality, if you can  -|manage it effectively.  -|  -|Gary  >R. 
> Patterson  -|  -|  -|  -|-----Original 
> Message-----  -|From:  >owner-midrange-l@midrange.com 
 >  
 >>-|[<<mailto:owner-midrange-l@midrange.com>mailto:owner-midrange-l@midrange.com>mailto:owner-midrange-l@midrange.com]On
 > 
 >  >Behalf Of midrange  -|Sent: Thursday, November 09, 2000 1:29 
> PM  -|To:  >MIDRANGE-L@midrange.com  -|Subject: Re: 
> programmer  >productivity.  -|  -|  -|I have been ask by accountants to 
> provide them  >with a way to measure our  -|programmers 
> productivity.  -|  -|  -|I know  >what I think is productive. fast 
> accurate turnaround on  >projects.  -|  -|does anyone one else have any 
> comments.  -|  -|thank you  >jeff grace  -|

+---
| 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
+---