From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.4 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, URIBL_SBL_A autolearn=ham autolearn_force=no version=3.4.4 Received: from minnie.tuhs.org (minnie.tuhs.org [50.116.15.146]) by inbox.vuxu.org (Postfix) with ESMTP id 8ACCE23246 for ; Thu, 4 Jul 2024 15:00:44 +0200 (CEST) Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 8C3CC4334E; Thu, 4 Jul 2024 23:00:37 +1000 (AEST) Received: from mail-ej1-x62f.google.com (mail-ej1-x62f.google.com [IPv6:2a00:1450:4864:20::62f]) by minnie.tuhs.org (Postfix) with ESMTPS id A0C6C43321 for ; Thu, 4 Jul 2024 23:00:27 +1000 (AEST) Received: by mail-ej1-x62f.google.com with SMTP id a640c23a62f3a-a77c1658c68so41839866b.0 for ; Thu, 04 Jul 2024 06:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1720098026; x=1720702826; darn=tuhs.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=PMtNKly7qUzIXJAEx98frfWOTxJe1hG13L9a7OTSPOo=; b=H5iGdZfwVmllCsB82TN/MoJeVPuM+9Rfl3vLcKE7FIhSk93eppzgHiK/9SdlemzNiz nW+SVsUwwJqUnpchQEelQwPbEqA1tisVc7tDraJJhoTO9ca+J8bMJ2QvqYD3yrNzZ6to zziBsor5IIbE0BYxAE6jlY3PWUwyF/uBx/AYu6EYskw0II1qckRE46fZEZSbdbhypFyf B8l10BgulSoSxcyb0KBJHbRWsvXhT9/IaL57SC343dR8NNXv0tPHckmABpzmiqx4V3Ly Nn0N/V456P1QJF2ATSQrnRgDpYUc/isSqn9kNZjGFJX9H/TPsr86/FYApVy3Rm0SwF8K RC+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1720098026; x=1720702826; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PMtNKly7qUzIXJAEx98frfWOTxJe1hG13L9a7OTSPOo=; b=J8B+McBb6HtVlcXvpyLVbgvUdK0JX0n6TFW+hBNECSGafpiX6GBsbB75p0ZUQqQ3rf 4B8UkKSUkBhb+cpgWV3KBc9YRadIKWfPFofEr346UC7+K7jMSrnVlfr3S0wGZN+C2U7e A7MLXuADw6KFXE2pvPCCc8fZ1hLH13SF8W9cZqnb/TD5BVoZRe6AMNIpsutVsbhwvZ3Z 5NLf2x+OX0GndA2+K25sHOblzW8xmzIpRYCUo2eZWZ46z1NKhN4D7Dhm11cqNUSqXhiV CKLZtVdX3TMLfQq4NkE8E6GUvYZ5yLtZ7xq1ZrRrFqEllnX1YG2ll5w4d7QxrtRNdr3H XYTg== X-Gm-Message-State: AOJu0YzsG9jzbHoTEUpUeKkjuYtIi7y1VJGPf+6mutcKFCxorfEN8WPs hyOGZs2BvwYM85omqfW5o4yNzEIG6kT7xakI1PpQ+m0ROD4hTPYglwccEtbClAistuCgu9WeSOA qChaDDW2afCcOQt7FU4SeaYuFy4s= X-Google-Smtp-Source: AGHT+IGwTXU2l+chweuWmO2Pub/zpZpCrQUGnQd+oRnpbUmm/vgq/sDd4ARx4CiB05TAPcb9sAT0bGuD4/o7UT+aWTM= X-Received: by 2002:a17:906:175b:b0:a77:a630:cf89 with SMTP id a640c23a62f3a-a77b9dee79dmr99363566b.0.1720098025215; Thu, 04 Jul 2024 06:00:25 -0700 (PDT) MIME-Version: 1.0 References: <93529CA0-7097-443C-999B-384BE6BD5683@canb.auug.org.au> <1b03f128-192f-4f46-4e76-50b68cd0e5af@bitsavers.org> <20240703233542.ceq73fqdlbgntrgg@illithid> In-Reply-To: <20240703233542.ceq73fqdlbgntrgg@illithid> From: Marc Donner Date: Thu, 4 Jul 2024 09:00:13 -0400 Message-ID: To: "G. Branden Robinson" Content-Type: multipart/alternative; boundary="000000000000c5a243061c6b8744" Message-ID-Hash: NQIZVC6H2IO7CJL4YDBSHVQ3PVEAAMB2 X-Message-ID-Hash: NQIZVC6H2IO7CJL4YDBSHVQ3PVEAAMB2 X-MailFrom: marc.donner@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tuhs.tuhs.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Anyone ever heard of teaching a case study of Initial Unix? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000c5a243061c6b8744 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Back in the mid-to-late 1980s I was the ringleader of the UNIX underground at IBM Research. Interestingly, we were for a couple of years the largest non-academic customer for Sun Microsystems on the east coast of the US. When IBM bought ROLM, a maker of telephone equipment, they were confronted with ROLM's insistence on using Sun equipment (and UNIX in general) for their software development. So a stream of IBM executives made their way to my office in Yorktown Heights to try to figure out whether this demand was for real. I would show them my development environment (emacs and make plus a bunch of ancillary tools) and demonstrate how I could edit code, build, test, and debug quickly and smoothly. After half a dozen VPs came through, they agreed and placed a large order with Sun for ROLM. That might have helped the business case for a better AIX, but I'm not sure. =3D=3D=3D=3D=3D nygeek.net mindthegapdialogs.com/home On Wed, Jul 3, 2024 at 7:35=E2=80=AFPM G. Branden Robinson < g.branden.robinson@gmail.com> wrote: > 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/archiv= es/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/archiv= es/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 > --000000000000c5a243061c6b8744 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Back in the mid-to-late 1980s I was the ringlea= der of the UNIX underground at IBM Research.=C2=A0 Interestingly, we were f= or a couple of years the largest non-academic customer for Sun Microsystems= on the east coast of the US.

When IBM= bought ROLM, a maker of telephone equipment, they were confronted with ROL= M's insistence on using Sun equipment (and UNIX in general) for their s= oftware development.

So a stream of IB= M executives made their way to my office in Yorktown Heights to try to figu= re out whether this demand was for real.

I would=C2=A0show them my development environment (emacs and make plus a= bunch of ancillary tools) and demonstrate how I could edit code, build, te= st, and debug quickly and smoothly.

Af= ter half a dozen VPs came through, they agreed and placed a large order wit= h Sun for ROLM.=C2=A0 That might have helped the business case for a better= AIX, but I'm not sure.


On Wed, Jul 3,= 2024 at 7:35=E2=80=AFPM G. Branden Robinson <g.branden.robinson@gmail.com> wrote:
=
At 2024-07-03T08:59:11-06= 00, Marc Rochkind wrote:
> Steve Jenkin suggests: "Developers of Initial Unix arguably were<= br> > 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.=C2=A0 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").=C2=A0 Naturally enough, pl= enty of
people who make claims about variance in programmer productivity are
unaware of this paper's existence; it's not actually relevant to th= em as
a source of knowledge.

https://web.archive.o= rg/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.o= rg/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.=C2=A0 Detecting a 20+:1 range ratio depend= s
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.=C2=A0 The dispersions of such da= ta
as appear in Table I are better represented by such measures as the
standard deviation or semiinterquartile range."

https://invisible-island.net/personal/paperstuf= f.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).=C2=A0 (If a member of one's audience is fa= miliar
with non-Gaussian distributions and inquires whether one's sample may b= e
better characterized by one, you invite them to disengage from the
discussion.)

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

1.=C2=A0 Immature Unix enthusiasts like to reassure themselves, and others<= br> =C2=A0 =C2=A0 nearby, of their inherent superiority to rival programmers.
2.=C2=A0 Managers like to contrive reasons for (not) promoting individual =C2=A0 =C2=A0 contributors.=C2=A0 It's easy to cite this productivity &= quot;statistic" and
=C2=A0 =C2=A0 then suggest, without indicating anything concrete, that an e= mployee
=C2=A0 =C2=A0 is either a rock star or a mediocrity.

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

=C2=A0 =C2=A0 https://en.wikipedia.org/wiki/Vitality_cu= rve

4.=C2=A0 Business culture in general is deeply wedded to the idea that
=C2=A0 =C2=A0 individual productivity, merit, or capacity for "wealth = creation" is
=C2=A0 =C2=A0 variable by several orders of magnitude, because this claim =C2=A0 =C2=A0 "justifies" variance in compensation over a similar= ly large range,
=C2=A0 =C2=A0 even among college-educated professionals in an organization,=
=C2=A0 =C2=A0 setting aside those members of staff whose collars shade more= toward
=C2=A0 =C2=A0 blue.=C2=A0 (Outsourcing is useful in increasing opacity, seg= regating
=C2=A0 =C2=A0 workers, and setting them up to have conflicting interests.)<= br>
=C2=A0 =C2=A0 If people start applying their capacity for critical thought = to the
=C2=A0 =C2=A0 proposition that the CEO is 40,000 times more productive than= a
=C2=A0 =C2=A0 "Software Engineer II", nothing good will happen.
_Is_ "productivity" among programmers, however defined and measur= ed,
nonuniform?=C2=A0 Likely yes.=C2=A0 Has our industry studied the question i= n a
serious way, applying rigorous experimental design and statistical
analysis?=C2=A0 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
--000000000000c5a243061c6b8744--