Software engineering (was Re: [SATLUG] IO-InfoOnly)

[Bruce Dubbs]

Travis H. wrote:
> On Tue, Dec 05, 2006 at 03:54:47PM -0600, Robert Pearson wrote:
>> The only coding "rule of thumb" measure I have heard of is IBM's
>> famous, or infamous, 10 lines of "tested" code a day.
> 
> That's odd.  I recall hearing somewhere, contrary to assertions in
> this thread, that the difference in productivity between the best
> developer and the worst (as measured in SLOCs) is several orders
> of magnitude.  

True.  It was first widely documented by Boehm: Software Engineering
Economics.

> It was argued, and I believe, that coding is one
> profession where this great disparity exists, and thus where
> proficiency can reap relative rewards that are out of scale for
> other professions.  For example, if you're a research chemist, I
> really doubt they care about how well you can titrate a solution.
> It just doesn't matter in the overall scheme of things, most of the
> time.  However, if one person can write 100 error-free SLOCs per
> diem, and another person gets out 1, then the former is far more
> valuable.

This has been documented in several places and matches the experience of
many.  Note that a programmer's productivity does not always translate
to another application domain.

> Of course, this assumes the code isn't being padded, that the
> code quality and density is equivalent... obviously anyone can
> unroll loops the cut-and-paste way...

One of the great "productivity enhancers" is reuse.  It always takes
more time to start from scratch than from a similar code base.  If
programmer A writes 100 SLOC/day and programmer B reuses 100 SLOC/day
and adds 10 more/day, which is more productive?

As I said earlier today, measuring SLOC is non-trivial.  You can't just
count newlines.

A few years ago I wrote a program to count SLOC for C/C++.  It counted:

lines with code
lines with comments
lines with both code and comments

I also wrote code to measure token counts, token length, tokens per
function, etc.  Its amazing what static analysis of code can show.
There was pretty good correlation between some of the metrics and
subjective evaluation by panels of evaluators of the code too.

For instance, in Linux 2.6.12.5's xfs filesystem code the c programs give:

Lines_of_code Blank_Lines Comment_Lines Comments_with_Code
        56887       19124         13559               4070

But all 79 files have 31 lines of comments at the beginning with the
copyright so the comment lines need to be reduced to 11,110.

BTW, this doesn't count .h files.

Can you tell from the above that the code is good?  No, but my initial
reaction is encouraging due to the comment density.  OTOH, I have no
idea how long it took to write this code or how many programmers were
involved.  I can say that if someone was writing a new filesystem that
looking at these metrics would give a first order approximation of what
it would take.

  -- Bruce