NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/lang/c/17006

Internet Message Format | 1992-11-22 | 2.7 KB

Xref: sparky comp.lang.c:17006 comp.software-eng:4456
Newsgroups: comp.lang.c,comp.software-eng
Path: sparky!uunet!haven.umd.edu!news.umbc.edu!gmuvax2!ofut
From: [e-mail] (A. Jeff Offutt)
Subject: Why are some programmers more productive?
Message-ID: <[e-mail]>
Organization: ISSE Department, George Mason University
References: <[e-mail]> <[e-mail]>
Date: Mon, 23 Nov 1992 01:33:43 GMT
Lines: 46

In article <[e-mail]> [e-mail] (Sridharan) writes:

>Try a hypothesis:  What if .. just what if .. the famous 80-20 rules works.
>Examples: 80 percent of the function comes from 20 percent of the code
>    80 percent of the value comes from 20 percent of the effort
>    80 percent of the result comes from 20 percent of the people (in a large
>project)
   ...
>get 80% of the most valuable work done in 20% of the effort; and
>if a "gifted" programmer is one who can apply the 80-20 rule twice over - and
>can get
>64% of the value with only 4% of the effort
>- Would this account for the variability in productivity?

I had an interesting experience in one of my classes last year that explains a
lot about "programmer productivity", especially the "super programmer" notion
(that some people produce 10 times, 100 times, whatever, more than others).

This is a software engineering team project course -- they go through
the whole process, from requirements to integration.  A kid who thought
he was a very good programmer (he'd done very well in previous classes)
came up with a design for his team's subsystem that, while very clever,
was very inefficient.  During the design review, they pointed out that
they were halfway through coding -- had already written 1000 lines of
code.  But I pointed out a severe flaw, and a way to reduce the size of
the subsystem coonsiderably.  This did not make them happy, until I
pointed out that they were now planning on writing about 1000 more
lines of code, and the new design would only require a couple of
hundred, so the new design was _still_ a net savings.

The point is, if you can write code much faster than I can, _and_ you
come up with a better design, the advantage is multiplied because you
start with less code to write.  This is what Brooks meant in his Silver
Bullet paper about fostering "great designers" ... a great design will
make everybody great programmers.


Jeff Offutt
Department of ISSE, George Mason University, Fairfax VA
email: [e-mail]
phone: [phone] (messages: 993-1640)
--
Jeff Offutt
Department of ISSE, George Mason University, Fairfax VA
email: [e-mail]
phone: [phone] (messages: 993-1640)