|
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 +---
As an Amazon Associate we earn from qualifying purchases.
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.