× 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.



Jeff Grace wrote:

> I have been ask by accountants to provide 
> them with a way to measure our
> programmers productivity.

This is a controversial subject indeed.  Basically, it boils down to the
same way any productivity is measured: How much "stuff" did you do, how long
did you take, how much did it cost you to do it, how well did you do it?

Each of these has wide variation in importance for every company.

"Stuff" can be: lines of code, function points, subroutines, programs,
flowcharts, etc.
"How long" can be: elapsed (calendar/clock) time, time booked to "stuff",
compile (machine) time, etc.
"How much" can be: number of edit/compile cycles, number of revisions after
beta, "how long", number of QA requests for clarification, etc.
"How well" can be: number of revisions to code after alpha, number of new
"stuff" added after alpha, number of bugs found by QA, number of deviations
from spec found by QA, number of deviations found by end users, number of
bugs found by end users, number of deviations from shop standards found by
peer review, how much money the project brought in, etc.

What your company deems important will determine what you want to measure.

Several keys:
1) Measure what is important to you.  Your programmers will do what they're
measured against.
2) Measure what is measurable.  The corollary is that if you automate the
measurements, you'll have an easy source of raw data.
3) Start measuring even if you have incomplete data.  You can refine later.

How I'd like to be measured:
Elapsed time to complete function points
Bugs/deviations found by QA
Bugs/deviations found in production

This means I get (or make) good requirements before I start, I don't dawdle
writing my code and I don't introduce bugs.  The emphasis would be on
quality, not quantity.  Just my opinion.  There can be a market for low
quality code as long as it's cheap... (same as anything else.)

Buck Calabro
Aptis; Albany, NY
"Nothing is so firmly believed as
 that which we least know" -- Michel Montaigne
Visit the Midrange archives at http://www.midrange.com
+---
| 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 ...


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.