wgh@ubbpc.UUCP (William G. Hutchison) (03/01/91)
I have been looking at schemes for measuring programmer productivity
and I have never found a method which handles the following scenario well:
Suppose a junior programmer needs to sort 10,000 character strings in a
UNIX application. He or she has not gotten very far in the algorithms course,
so the proposed solution is a bubble sort of about 50 NCSL (non-comment
source lines).
So the junior programmer gets 'credited' with 50 NCSL of productivity, or
whatever measure our employer uses.
Now, I see the program, and I modify it to use the UNIX library routine
qsort(3). Net change: improved speed and fewer source lines: 10 instead of
50.
Now what happens?
(1) am I congratulated for improving the program, and is the junior
programmer given a brief lecture about reusing standard software
components, or
(2) is the junior programmer credited with 50 NCSL of productivity, and
am I credited with -40 NCSL (which implies that I have destroyed some
corporate assets.)?
Any suggestions?
--
Bill Hutchison, DP Consultant psuvax1!burdvax!ubbpc!wgh (work)
Unisys UNIX Portation Center uunet!eidolon!wgh (home)
P.O. Box 500, M.S. B121 "At the moment I feel more like arguing than
Blue Bell, PA 19424 being good" Raymond Smullyan _The Tao is Silent_khb@chiba.Eng.Sun.COM (Keith Bierman fpgroup) (03/04/91)
>Bill Hutchison, DP Consultant psuvax1!burdvax!ubbpc!wgh (work) .... > (2) is the junior programmer credited with 50 NCSL of productivity, and > am I credited with -40 NCSL (which implies that I have destroyed some > corporate assets.)? Prize negative ratings, and reward those who can attain them. In the best parts of systems, things get simpler .... or at least the complexity moved elsewhere ;> -- ---------------------------------------------------------------- Keith H. Bierman kbierman@Eng.Sun.COM | khb@chiba.Eng.Sun.COM SMI 2550 Garcia 12-33 | (415 336 2648) Mountain View, CA 94043
mcgregor@hemlock.Atherton.COM (Scott McGregor) (03/05/91)
>In article <785@ubbpc.UUCP>, wgh@ubbpc.UUCP (William G. Hutchison) writes: > > I have been looking at schemes for measuring programmer productivity > and I have never found a method which handles the following scenario well: Is the problem is that you have not found an automatically generated metric, or do you really mean a method (which might be manual in part?). How do you determine that a method is not handling the situation well? For instance, I find actually looking at the code occasionally is a method that seems to handle the situation well. > Suppose a junior programmer needs to sort 10,000 character strings in a > UNIX application. He or she has not gotten very far in the algorithms > course, > so the proposed solution is a bubble sort of about 50 NCSL (non-comment > source lines). > So the junior programmer gets 'credited' with 50 NCSL of productivity, or > whatever measure our employer uses. > Now, I see the program, and I modify it to use the UNIX library routine > qsort(3). Net change: improved speed and fewer source lines: 10 instead of > 50. > Now what happens? > > (1) am I congratulated for improving the program, and is the junior > programmer given a brief lecture about reusing standard software > components, or Under the method I use with my engineers, your code would be inspected (perhaps by me) and you would be commended for your improvement. The reason for your change being an improvement (less to maintain, general presumption of higher correctness and performance in system provided routines) would also be discussed--no lecture to the junior programmer is necessary, since the reasoning is discussed during the review. Good junior programmers can learn quickly not just about qsort, but about the thought processes and habits (reading the system routines man pages occassionally) of the more experienced programmers that make them successful. Alternatively, this might have been discovered during the review of the junior programmers code, and I might ask questions about the use of the bubble sort, and why system provided routines were not used. The programmer might then figure out how to improve their code (switch to qsort) on their own. In which case, the junior programmer gets credit for learning, and the senior programmers contribution is unneccessary to avoid the problem. > (2) is the junior programmer credited with 50 NCSL of productivity, and > am I credited with -40 NCSL (which implies that I have destroyed some > corporate assets.)? In my method, the junior programmer would get credited with 50 NCSL, and you 60 "changedNCSL". But I don't know how to interpret "50 NCSL *of productivity*". From my perspective NCSL is a measure of number of lines of code to maintain, not a measure of productivity. Fewer lines to maintain are better, given equal functionality. Even NCSL/month is only a limited measure of productivity. To get productivity, you need to factor in at least two things: 1) The relative density of functionality to lines of code: Some programmers find ways to achieve lots of functionality in a few lines of code (using system routines is only one way), where others do not. It is the functionality/month that is a more real measure of productivity. 2) The amount of existing code; you want to measure the total amount of code *handled*, not merely additional lines of code. Maintenance and new development both handle lines of code, but new development is more likely to add code than replace it. When the Jr. Programmer wrote those fifty lines, they were fifty new lines. While your solution reduced the total amount of lines by forty, you actually HANDLED 60 lines; there were the old 50 lines you removed, and the ten new lines you added. Diff routines can give a good hint as to how much code was handled, not just the total amounts of the code before and after, but again inspections are particularly effective. I don't find that inspections NEED to be formal, but they can be if you like. It has been my observation that some experienced programmers *often* reduce their total number of lines of code a lot if given enough time, and that they work by incremental refinement. What often happens is that new functionality is added by additional pieces until the total amount of desired fuctionality is mostly achieved. Then the programmer starts to notice they wrote parallel solutions for different components and they begin to finds ways to simplify by rewriting routines for greater generality and reuse in multiple areas of the code. Sometimes additional functionality is gained through this generality as well. Some other experienced programmers work differently. Instead of doing incremental refinement, they study and make notes for a long time. They don't start writing code very quickly--but once they do begin to write it tends to come quickly, be already be generalized, and makes fewer changes to their code. You don't see the code decreases as much with this type of person. I sometimes call this Mozart school, and the other more reworking style the Beethoven school. (This may not be accurate, but it is memorable and names help when talking about the two approaches). Both styles seem to me to be equally effective. Forcing a person who naturally prefers one to use the other style usually damages their productivity and morale. It requires some flexibility among the manager and co-workers to deal with people with different approaches, but seems to get the most out of people's personal strengths. Scott McGregor Atherton Technology mcgregor@atherton.com
jls@rutabaga.Rational.COM (Jim Showalter) (03/05/91)
I think programmers should have their sloc evaluated in terms of how
much came from reuse libraries and how much didn't--the higher the
ratio of reused to non-reused, the better the evaluation.
In short, the question is not "How much code did you write", but
"How much code DIDN'T you write".
--
***** DISCLAIMER: The opinions expressed herein are my own. Duh. Like you'd
ever be able to find a company (or, for that matter, very many people) with
opinions like mine.
-- "When I want your opinion, I'll beat it out of you."