> I have heard about 20 SLOC/hour being the realistic developer’s
productivity as
a long-term (months) average - in a short burnout period, the developer
can
surely write more then 20 SLOC/hour.
The productivity numbers I talked about were NOT about how many lines of
code can someone type into an editor, they were about how much actual usable
work does a programmer get done over longer time periods. You have to take
into account the week you spend debugging an ugly problem and wrote zero
lines.
The link at http://www.theadvisors.com/langcomparison.htm has some not too
old numbers (1996). This link is essentially a free link to older numbers
from SPR Inc (who analyzes project data and charges for what they find). For
the C language it says 128 average lines of source code per function point
and the “language level” for C as 2.5. Another table on that page says the
productivity average per staff/month for language levels 1-3, which would
include the C language, says you get 5-10 function points per staff month.
Doing the math that means you get 640-1280 lines per staff/month. Converting
to staff years gives 7,680-15,360 lines of C code per staff/year. If you
have no life outside of work, and spend all your waking hours doing
development, then these numbers are probably low.
I added up the source files for the e100bex Ethernet NIC in the DDK\src
branch as 13632 lines of code (.c + .h files).
Just as a reality check, I’d be curious to hear from people on this list how
long they think it would take to write the e100bex driver, 3 months, or
would it take more like a year?
Using source code metrics to judge staff productivity is a little bogus, as
if you’re being judged based ONLY on source lines, it’s really easy to have
a lot of comments.
As a way to estimate project cost, and staffing requirements, I think source
code size estimates are quite valuable. I can look at the DDK and say a
device like a e100bex takes about 13,000 lines of C code, which I would
probably translate into “about a man/year”. If a project is going to take
about 300,000 lines of code (anybody know how many lines in the NVidia
drivers, the binaries are like 4 Mbytes), then you are probably going to
need a staff of like 10 developers over 3 years. As projects get bigger,
software written is not a linear function of staff size (read The Mythical
Man-Month), as the communication overhead becomes non-trivial.
My guess is Microsoft has looked at their development productivity quite a
bit. My guess also is they don’t have any magic that makes their
productivity that much different than the rest of the industry.
By bias is that the computer language you use matters quite a bit. If you
look at the productivity tables mentioned above, they suggest that writing
in C++ has about twice the productivity as C. This matches my experience of
C vs. C++, and only applies if you are skilled on both languages. I’ve heard
a developer say he could do a driver faster in C than C++, and I don’t doubt
that was true for that developer at that time. The question is if that
developer became very skilled in C++ would they still say they could get
more done on C. I know it took me a number of years before I actually
believed C++ was a better language than C for driver development, but now I
strongly believe it to be so.
I do think it would be useful for Microsoft to look at the development of
Windows, and have a section in the DDK about how to estimate the complexity
of different kinds of drivers. I know my current client was a little bit in
shock when I told them how much work I thought their project would be. Of
course maybe having unrealistic estimates is a requirement to convince the
venture capitalists to give you money (so staying ignorant gives management
a good excuse). I’ve seen more than one startup fail because their
assumption about Windows driver development costs were very wrong. Hardware
companies especially, often put all their resources in developing the
hardware, the drivers become an afterthought with no budget. This is a
significant reason why the quality of so many drivers is so bad. The only
solution seems to be better education and estimating info. Perhaps OSR
should do a training session for management on how to make realistic
estimates of driver projects.
- Jan
