Which is, of course, included as “The story of Mel” in the jargon file:
But looking back on it, I would say out of my current perspective this Mel guy was not a genius, but one of the worst programmers you could probably hire:
He written unmaintainable and even unchangeable "write-once" code that was so complex that nobody else could handle it either. He refused to do what he was payed for and just went away as he lost interest.
One of this kind of dudes on your engineering team and your company is in real deep trouble…
It's a given that you will need to throw away everything they did and start form scratch should any changes be necessary later on. However there's one fundamental constant in software engineering: Your software is going to need to change over time! No mater whatever somebody told you upfront. So in case you've got software built by some "Mel" you're completely screwed at that point, especially as changes to SW are usually needed the most at some critical period in time for your company.
Obviously not. We're talking about mundane business software.
Also the "optimizing compiler" that couldn't reach such levels of "perfection" wouldn't be a thing if this would really matter.
> Mel's tricks were just how things were done back then.
Obviously not. Otherwise there wouldn't be any point in this story.
It points out, with a lot emphasis, how exceptional Mel's code was!
> There was no repo, code didn't need to be maintained or added onto.
VCS dates back quite some time…
Also maintaining code was of course not any less important for a company as it is today. Simply as companies back than also relayed on their software to operate.
> The lifecycle of software was much much shorter.
No, of course not, as nobody would throw away some very expensive asset for no reason.
If anything, lifecycles of software were much longer than today (when you can deploy changes every few minutes if you please). Stuff written in the 70's is still running on some mainframes today!
As changing software was much more dangerous with much higher risk of breakage, less experts around, and everything much more difficult in general, it was more usual to try to not touch an already running system. (Maybe you even heard some quite similar proverb coined back than ;-)).
But "not touching" it does not work, as there is only one truly constant thing: Change.
But it's quite strong. B-)
Let's see. From the story:
>I first met Mel when I went to work for Royal McBee Computer Corp... [The firm] had just started to manufacture the RPC-4000
https://en.wikipedia.org/wiki/LGP-30#RPC_4000
> the General Precision RPC 4000, announced in 1960
https://en.wikipedia.org/wiki/Version_control#History
>IBM's OS/360 IEBUPDTE software update tool dates back to 1962, arguably a precursor to version control system tools. A full system designed for source code control was started in 1972, Source Code Control System for the same system (OS/360).
The events of the story predate the precursors of VCSs by two years, and the earliest true VCS by a decade.
I can't find any definitive info when this computer got actually manufactured ("announced in 1960" doesn't mean strictly the same). But this was the time Mel was met first time by the author.
The story plays likely some time thereafter.
I guess some significant time, because it takes time even for a genius to become familiar enough with a machine to do all this kind of trickery described in the story.
I think it may make sense to assume even some years passed between when the author met Mel the first time and Mel's departure form said company.
So I wouldn't be even so much off with the VCS statement—which actually doesn't state any relation between the usage of VCS and the story. I've only said that "VCS dates back quite some time". Which is obviously true. ;-)
But, all this actually doesn't matter.
The more important statement was the following. Which is a direct reply to "code didn't need to be maintained", which is in my opinion just not true.
I did not say VCS was used back than for that purpose.
I guess they preferred more a sort of solid hard copy. :-)
Certainly if you were a business, you had an extreme business interest in keeping your "known good" stack of cards in a place, and every revision in code required a new stack of cards.
"Hey, the machine just ate 10 cards from the payroll software, can we get duplicates made?"
"No, those were the originals, guess we're SOL no one gets paid" never happened.
Most likely "Ok, version 1.34 of the payroll software that was updated last week? Cards 1032 to 1042? Duplicate cards will be up to you within the hour"
or "We have to revert to the old payroll processing software, can you create a new fresh copy of 1.33, 1.34 has some bugs and we need to get tonights run in?"
There are lots of problems that are specific and simple enough to solve, that it's easier to write a C program from scratch, than it is to find, install and then learn how to do it with some existing package... The same concept goes for programs.. At a certain scale, it's not worth the extra infrastructure/overhead/rigidity/complexity that it takes to write software that's optimized for change.
That said, today, in 2022, it's more or less the opposite, codebases are huge enough that most of software "engineering" is about plumbing together existing libraries, and at that scale, it's an entirely different thing.
We're not talking about embedded software with special constrains here!
This story is about mundane enterprise software.
Nothing in the story justified this insane level of over-engineering and premature optimization.
Just using the "optimizing compiler" was deemed "good enough" for all other needs of the company, likely…
Also nobody asked for that over-"optimized" throw-it-away-and-start-over-if-you-need-to-amend-anything-crap.
I have still this warmth nostalgia feeling when looking at this story, but when thinking about it with quite some experience in real world software engineering I'm very sure that this kind of programmer would be one of the worst hires you could probably run into.
Finding any valid excuses for "write-only" code is hard, very hard. This was also true back in the days this story plays.
Sorry for destroying your nostalgia feeling, but please try to look at it from a professional perspective.
Otherwise it makes no sens. Computers back than where very expensive. You wouldn't use them for anything that wouldn't yield income in some way.
It quite clearly wasn't a "computer game" in today's meaning.
I would call "marketing support software" indeed "mundane enterprise software".
Not so for anything shipped on ROM.
Maybe that's even the point that makes me like the story as such very much.