× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: RE: programmer productivity.
  • From: Evan Harris <spanner@xxxxxxxxxx>
  • Date: Tue, 14 Nov 2000 19:14:40 +1300

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.