I recently reported on the Siemens number of an average 1500 lines of
debugged and documented code per programmer and year and the 10
lines/day in an industrial setting that appeared in the notes for a
course on The Mythical Man-Month. Others contrasted it with various
stories of writing a lot of code in a short time.

One issue with the numbers I cited is that they are pretty old. I
heard the Siemens number in the 1980s and the number from the course
on The Mythical Man-Month are probably also pretty old (the book is
from 1975). How have newer software engineering practices changed
that?

In comes an article that discusses, in it's "Looking back" part, the
development statistics of Linux between October 31, 2021 (release of
Linux 5.15) and December 11, 2022 (release of 6.1)
<https://lwn.net/SubscriberLink/915435/5e0c13017251d9f6/>, i.e. in 426
days.

It says that the kernel had a net growth of 3.7M lines from patches
from 5034 developers (735 lines/developer; or 630 scaled to 365.24
days); but of course many of these developers may not have worked on
the Linux kernel full-time during these 426 days. OTOH, some of these
lines may come from work that may have been done earlier, and only
come into the mainline in this timespan, but this may be offset by
these developers working on patches that did not reach the mainline in
this timespan.

We also see statistics about the most prolific developers "by changed
lines" (note that these are not added lines, although I guess that
many are added; it's easier to get a high line count for adding or
removing code than for modifying it). The seven highest-ranked ones
(with 152525-341685 lines each) work for AMD and contributed large
numbers of lines for AMDGPU register definitions (which were hopefully
automatically generated from internal data at AMD). The #20 rank
changed 28611 lines (24530 per 365.24 days), which is about an order
of magnitude higher than the old numbers, but than he is in the top
0,4% of contributors. The question is how many of these changed lines
are documentation (would not count for the old metrics), how much
reviewing and testing of other code this developer did in that time,
and how much time other developers spent on reviewing, testing, and
debugging these 28611 lines.

Looking at those numbers, the number of lines of code per developer in
the Linux kernel may or may not be higher than what was reported for
Siemens or The Mythical Man-Month; I expect that it is higher, just by
using better software tools and a less bureaucratic and more
meritocratic process, but it's not clear from these numbers what the
actual average productivity is (let's leave aside the issue of whether
measuring productivity in lines/time is a good metric).

And of course, the numbers from the top 7 prolific contributors raise
the question of how to separate automatically generated, or, as others
have mentioned, copy-pasted lines from lines that require more thought
in production.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On Saturday, 17 December 2022 at 13:24:36 UTC+1, Anton Ertl wrote:
>
> I recently reported on the Siemens number of an average 1500 lines of
> debugged and documented code per programmer and year and the 10
> lines/day in an industrial setting that appeared in the notes for a
> course on The Mythical Man-Month. Others contrasted it with various
> stories of writing a lot of code in a short time.

It depends altogether on how high-level a language is, as well as,
and even more importantly, on having or not having a decent
analysis and design to start with: but, for the better end of that
spectrum, assuming a high-level language and that we have a
good design already, a professional expert programmer can
produce up to 500 to a 1000 production-level LOC per week...

> One issue with the numbers I cited is that they are pretty old. I
> heard the Siemens number in the 1980s and the number from the course
> on The Mythical Man-Month are probably also pretty old (the book is
> from 1975). How have newer software engineering practices changed
> that?

For the absolute worse: since the mid 90's it's been a complete
fraud and sabotage across the whole spectrum... Indeed, despite
our technologies as well as toolsets are way more powerful than
they were back then, in reality it is pretty much never the case that
the programmer is given a decent design and even less a sensible
analysis, and that's just the leaf of the iceberg... not per chance
nowadays typical software projects are not just light-years shy of
anything production-level, but also they typically coast (and cost)
indefinitely, usually dying before even getting near to their goals...

And in these nowadays typical and "normal" circumstances, indeed
productivity is at best 100 production-level LOC a week, and if we
insist on the production-level, in fact rarely even 10... Which is how
those figures are in fact still quite right for a meanwhile totally
deranged software industry.

Julio