|
If your programmers know that you measure productivity by LOC then the measurement is useless. How do you distinguish between cut & paste lines of code vs new lines of code. Modified lines of code vs lines where only the spacing/capitalization was changed ? I can modify all of the lines of a program in no time at all. I have seen the following: (as I am sure everyone else here has too) (pseudo code) if Row = 11 and column = 10 exsr prompt goto again endif if Row = 11 and column = 11 exsr Prompt goto again endif ... for all 10 columns of the field very productive !!! if Row = 11 and column >=10 and Column <=19 exsr Prompt goto again endif Well this re-write was very un-productive !!! On the other hand if you measure bugs then who decides which programmer is responsible for the bug ? If you ever have telco problems don't be suprised if the problem is fixed and the technician reports "no trouble found" I am told this relates to their performance rating. There is a dilbert cartoon where the pointy haired boss offers $25 for every bug found ... Wally declares "I'm going to write myself a mini-van" Project delivery and quality control is the only measurement of productivity. The problem with that is we don't know how to estimate how long it should take to complete the project!!! And who decides what is a quality/bug issue and what is a revision. John Hall Richard Jackson wrote: > > Alan: > > I can find no end of documents to show that no other productivity-measuring > system offers a substantial advantage over LOC. Note, I am not saying that > LOC is good only that nothing else is much better. > > One does not compare LOC across languages. As you pointed out, that is a > silly idea. > > Since you have attacked LOC is such an "involved" way, would you like to > suggest a method that you believe will work better so that we may attack > you? > > <bg> (I'm not very committed to this discussion) > > Measuring productivity is a pretty silly idea too. If you believe that you > can measure productivity using a simple technique that is easy to understand > then you also believe that programmers perform mechanical work and that they > should be a commodity item. Good luck filling programming positions. If > you are willing to accept that the job is complex and technical then you > must also accept that the measurement technique will be complex (subject to > interpretation) and you will not understand what the programmer is doing. > When you don't understand it, at least part of the time the measurements > will not make sense. > > The OP should monitor each fix through its lifetime. Fixes move through > stages defined by a process model. Status reporting identifies where each > work order is in the process. Allow management to understand how long each > stage should take and how long it actually did take. > > Richard Jackson +--- | 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.