A friend of mine at IBM Research told me the following experience from his early career.

He was hired to join the MVS development team in Poughkeepsie (or Endicott?) right out of school.

He got the "new kid" assignment - maintaining the JCL interpreter.  500K lines of H Assembler (might have been G Assembler ... disremember).

The job was to take bug tickets, analyze them, and respond with either a fix or a rejection.

After a bit of this he thinks to himself, "Self, this is a programming language, but badly implemented in assembler with lots of copy-paste crap."  He had studied computer science in college, so he knew something about compiler implementation.

So he builds a set of parser tables using what he learned from the Dragon Book and implements a new JCL interpreter in PL/1 (or PL/S?).  About 20K LOC.

The new JCL interpreter is faster, though that doesn't really matter.  More importantly, it also closes hundreds of bugs that arose from the fact that many of subcommands had suboptions with variant implementations, even though they were *supposed* to be the same suboption.

So, come annual review time he gets the most negative possible score.  Why?  Because he produced -480K lines of code.

So he transferred to the Research Division where his skills were more valued and where I met him.


On Tue, Oct 11, 2022 at 10:00 AM Warner Losh <imp@bsdimp.com> wrote:


On Tue, Oct 11, 2022 at 7:49 AM Larry McVoy <lm@mcvoy.com> wrote:
On Tue, Oct 11, 2022 at 01:15:38PM +0200, Paul Ruizendaal via TUHS wrote:
> There is also another anecdote involving Atkinson. At some point all Apple programmers had to file a weekly report with how many lines of code they wrote that week. After a productive week of refactoring and optimising, he filed a report saying "minus 2,000 lines".

We bonused people for that.

I love commits like this, thought it wasn't refactoring so much as deleting obsolete code...

commit c09981f1422ef0d44042dacc5d1265392fba39f1
Author: Warner Losh <imp@FreeBSD.org>
Date:   Thu Dec 30 20:56:09 2021 -0700

    mips: Remove sys/mips

    Remove sys/mips as the next step of decomissioning mips from the tree.
    Remove mips special cases from the kernel make files. Remove the mips
    specific linker scripts.

    Sponsored by:           Netflix
...
 594 files changed, 4 insertions(+), 134,562 deletions(-)