The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
To: tuhs@tuhs.org
Subject: [TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix?
Date: Wed, 3 Jul 2024 18:35:42 -0500	[thread overview]
Message-ID: <20240703233542.ceq73fqdlbgntrgg@illithid> (raw)
In-Reply-To: <CAOkr1zXkTGYZ6svXEQNr7qUwPALf0wrJGU+HwWu-ZU+i+iV4sQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4494 bytes --]

At 2024-07-03T08:59:11-0600, Marc Rochkind wrote:
> Steve Jenkin suggests: "Developers of Initial Unix arguably were
> 10x-100x more productive than IBM OS/360..."
> 
> Indeed, this is part of accepted UNIX lore.

That claim reminds me of a more general one.  Applied to software
development writ large, it seems to be lore, not a reproducible
scientific result.

I refer of course to Sackman, Erickson, and Grant's 1968 CACM paper
which documented a DARPA experiment that found a productivity range of
28:1 in their sample of programmers (with veterans of 7 years'
experience pitted against "trainees").  Naturally enough, plenty of
people who make claims about variance in programmer productivity are
unaware of this paper's existence; it's not actually relevant to them as
a source of knowledge.

https://web.archive.org/web/20120204023412/http://dustyvolumes.com/archives/497

Thomas Dickey, better known today as the maintainer of ncurses, xterm,
lynx, and mawk (all for 30 years or more, and among other projects),
published a critique of this study in 1981.

https://web.archive.org/web/20120204023555/http://dustyvolumes.com/archives/498

Bill Curtis published a critique of the Sackler et al. paper in 1988.

I quote (via Dickey):

"Sackman's ... message that substantial performance differences do exist
among programmers remains valid.  Detecting a 20+:1 range ratio depends
upon having one brilliant and one horrid performance in a sample.
However the range ratio is not a particularly stable measure of
performance variability among programmers.  The dispersions of such data
as appear in Table I are better represented by such measures as the
standard deviation or semiinterquartile range."

https://invisible-island.net/personal/paperstuff.html

We have likely all observed how this 28:1 ratio has bloated in retelling
over time, like the length of a fish catch, to 100:1 or even 1000:1.
Similarly we're all familiar with the common practice of presenting the
mean and sometimes the range of some data sample to support one's
argument, without mentioning the median or mode, let alone the variance
(or the standard deviation).  (If a member of one's audience is familiar
with non-Gaussian distributions and inquires whether one's sample may be
better characterized by one, you invite them to disengage from the
discussion.)

I assert that this "productivity gap" is a myth, and that it persists
because it serves the purposes of diverse audiences who adopt it with
motivated reasoning.

1.  Immature Unix enthusiasts like to reassure themselves, and others
    nearby, of their inherent superiority to rival programmers.

2.  Managers like to contrive reasons for (not) promoting individual
    contributors.  It's easy to cite this productivity "statistic" and
    then suggest, without indicating anything concrete, that an employee
    is either a rock star or a mediocrity.

3.  Directors in organizations like not having to further justify a
    "stack-rank and cut" approach to reducing salary and benefits as a
    proportion of operational expenditures.

    https://en.wikipedia.org/wiki/Vitality_curve

4.  Business culture in general is deeply wedded to the idea that
    individual productivity, merit, or capacity for "wealth creation" is
    variable by several orders of magnitude, because this claim
    "justifies" variance in compensation over a similarly large range,
    even among college-educated professionals in an organization,
    setting aside those members of staff whose collars shade more toward
    blue.  (Outsourcing is useful in increasing opacity, segregating
    workers, and setting them up to have conflicting interests.)

    If people start applying their capacity for critical thought to the
    proposition that the CEO is 40,000 times more productive than a
    "Software Engineer II", nothing good will happen.

_Is_ "productivity" among programmers, however defined and measured,
nonuniform?  Likely yes.  Has our industry studied the question in a
serious way, applying rigorous experimental design and statistical
analysis?  Perhaps not.

And if we did, would any of the people making this claim read or
comprehend the research if it didn't support their biases?

You already know the answer.

We utter myths about falsifiable propositions not because we care about
their truth values, but precisely because we don't.

Regards,
Branden

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-07-03 23:35 UTC|newest]

Thread overview: 84+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-03  4:51 [TUHS] " sjenkin
2024-07-03  5:02 ` [TUHS] " Al Kossow
2024-07-03  6:46   ` arnold
2024-07-03 14:04   ` Clem Cole
2024-07-03 15:22     ` Theodore Ts'o
2024-07-03 15:36       ` Larry McVoy
2024-07-03 14:59   ` Marc Rochkind
2024-07-03 23:35     ` G. Branden Robinson [this message]
2024-07-04 13:00       ` Marc Donner
2024-07-03  9:04 ` A. P. Garcia
2024-07-03 15:17 ` Vincenzo Nicosia
2024-07-03 15:35   ` Marc Donner
2024-07-03 17:39     ` Jon Forrest
2024-07-03 17:49       ` segaloco via TUHS
2024-07-03 18:16         ` Erik E. Fair
2024-07-03 19:58         ` Rich Salz
2024-07-03 23:15     ` Dave Horsfall
2024-07-03 23:23       ` Marc Donner
2024-07-03 23:26       ` Rik Farrow
2024-07-04 23:26         ` Dave Horsfall
2024-07-03 15:37   ` Al Kossow
2024-07-03 16:01     ` Al Kossow
2024-07-03 16:05       ` Warner Losh
2024-07-03 23:29   ` Marc Rochkind
2024-07-03 23:50     ` G. Branden Robinson
2024-07-04  8:23     ` Vincenzo Nicosia
2024-07-04 20:34       ` Nevin Liber
2024-07-04 20:44         ` segaloco via TUHS
2024-07-04 21:41           ` sjenkin
     [not found]             ` <7AC009E5-C985-44AD-A55E-E0BFC05CDD31@serissa.com>
2024-07-05  9:41               ` Steve Jenkin
2024-07-05  9:47               ` Steve Jenkin
2024-07-05  0:03         ` Stuff Received
2024-07-05  0:12           ` Larry McVoy
2024-07-05  2:24             ` Adam Thornton
2024-07-05  2:42               ` Bakul Shah via TUHS
2024-07-05  7:13                 ` arnold
2024-07-05  7:42                   ` Bakul Shah via TUHS
2024-07-05  8:20                     ` arnold
2024-07-05  8:52                       ` G. Branden Robinson
2024-07-05  7:36               ` Dave Horsfall
2024-07-05 10:18                 ` Peter Yardley
2024-07-05 21:38                   ` [TUHS] Re: mental architecture models, " John Levine
2024-07-05 21:49                     ` Larry McVoy
2024-07-05 22:08                       ` Charles H Sauer (he/him)
2024-07-05 22:24                         ` Larry McVoy
2024-07-05 23:17                       ` John Levine
2024-07-06 12:52                         ` sjenkin
2024-07-06 14:02                           ` John R Levine
2024-07-06 15:58                           ` Clem Cole
2024-07-06 20:56                             ` John R Levine
2024-07-06 21:32                               ` Charles H Sauer (he/him)
2024-07-06 23:46                                 ` Peter Yardley
2024-07-07 17:43                                   ` James Frew
2024-07-07  1:39                                 ` John Levine
2024-07-07  3:26                                   ` [TUHS] Re: PL.8 [was " Charles H Sauer (he/him)
2024-07-07  5:33                         ` [TUHS] " arnold
2024-07-05 22:10                     ` Dan Cross
2024-07-07 22:00                   ` [TUHS] " Dave Horsfall
2024-07-07 23:28                     ` Brad Spencer
2024-07-08  6:17                       ` Dave Horsfall
2024-07-08  6:27                       ` Lars Brinkhoff
2024-07-08  6:51                         ` Dave Horsfall
2024-07-08  9:36                           ` David Arnold
2024-07-08  6:59                       ` arnold
2024-07-08 13:22                         ` Larry McVoy
2024-07-08 15:37                           ` Al Kossow
2024-07-08 17:22                             ` Tom Lyon
2024-07-08 17:04                           ` Clem Cole
2024-07-08 15:28                         ` Brad Spencer
2024-07-08 15:33                           ` Al Kossow
2024-07-08  0:21                     ` John Levine
2024-07-08  0:35                       ` Dave Horsfall
2024-07-08 12:29                     ` Peter Yardley
2024-07-05 16:40                 ` Jon Steinhart
2024-07-06 13:20                   ` Dave Horsfall
2024-07-05  0:08       ` Marc Rochkind
2024-07-04  1:53 ` John Levine
2024-07-04  2:59   ` segaloco via TUHS
2024-07-04  6:53     ` Rob Pike
2024-07-04 15:07       ` Larry McVoy
2024-07-03 14:46 [TUHS] " Norman Wilson
2024-07-03 15:45 ` [TUHS] " Clem Cole
2024-07-03 15:52   ` Clem Cole
2024-07-03 16:12   ` Chet Ramey via TUHS
2024-07-05 13:20 Douglas McIlroy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240703233542.ceq73fqdlbgntrgg@illithid \
    --to=g.branden.robinson@gmail.com \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).