RE: RE: programmer productivity.

I like these little debates. Far more interesting than finding out how the 3^rd 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]
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]  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
>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]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]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
+---