The story of Mel (1983)

Being "The Web Guy" sucks a lot.

What you've said is the equivalent of saying Odysseus would have been so much better if only he'd brought a cell phone with him, so he could call his wife and let her know when he'd be back.

Anyway, to understand the context of this article, you need to read the "parent post" called "Real Programmers Don't Use Pascal": http://www.pbm.com//~lindahl/real.programmers.html

And to understand that, check on the grandparent, not a post but a book: Real Men Don't Eat Quiche (http://en.wikipedia.org/wiki/Real_Men_Dont_Eat_Quiche).

I remember from "No Silver Bullet" (or was it "Mythical Man Month") how at one time it was a revolutionary idea to store documentation/comments along with the source code. It sounds crazy to ever have done it differently, but in earlier times, disk space was probably too scarce to do that. Likewise I suppose Mel's style was appropriate for the machines of his time.

Indeed, back then, memory addresses were more expensive than programmers. "Wasting" a week writing "unmaintainable" code to save a few bytes was apparently cost-effective.

Now, programmers are the expensive part. It follows that our code is now optimized for programmers rather than the hardware it will run on.

Undocumented: This one sticks, although perhaps Mel just never got around to writing documentation for the same reason he never got around to fixing the cheat bug. In any case, Real Programmers may not write many comments, but they do write external documentation, and often far more documentation than code.[1]

Unreliable, highly fragile: The story doesn't imply that the program was unreliable, and in fact the ending implies that the program was still working for some time after it was written, even though no one could really maintain it. Writing code that is tightly coupled to certain hardware features is not a good idea for most programmers these days who build on software APIs, usually at the top of a huge stack, and who want to be portable, but Mel didn't live in that kind of environment and wasn't aiming for portability. Even today, there are still places where code is written for known hardware and not on top of a stack of software that is going to be updated and patched and changed continually until the day it is no longer maintained (at which point, of course, it rots furiously).

Given the assumptions Mel was working under, he might very well have written code that lasted much longer, with zero maintenance, than most maintained code lasts. There are many advantages to portability and huge software stacks, but most programmers are so used to them that they have only the vaguest notions of the tradeoffs involved (it's not just performance).

Invalid: Ah yes, the hotshot programmer who thinks he knows better than the business people and refuses to implement perfectly good features because they go against his "principles", or "aesthetic sensibilities" wrt the code, or some such nonsense that has nothing to do with making the largest possible amount of money by doing something that Other People Want. Well, guilty as charged, but I am going to defend Mel on general principle here.

This part of the story resonates with some programmers because 1) like anyone else, programmers prefer to work on things that make the world a better place, or at least make themselves some money, as opposed to making scumbag upper management types 0.n% richer, especially if it is at society's expense, and 2) they hate the fact that they are seen as replaceable cogs in an IT machine that provides a messy but necessary service that any bunch of monkeys could do, and 3) if they are doing what any monkey could do, they are working on getting a job, or starting a company, where the technical envelope is being pushed to the point where it actually does matter how things are implemented, and where the problems are interesting enough that you can't grok the code just by skimming it, no matter how well it's written, because understanding it properly requires specialized knowledge that is not shared by every single programmer who's ever half-assed their way to a sheepskin, knows how to use Google, and hasn't burned out yet.

Encapsulation: Who says Mel didn't write well factored code? You can split things up by functionality in any language. Besides, Real Programmers write their own languages,[2] and the languages they write are designed from the ground up to provide more fine grained separation of functionality than you'll get in any managed bondage language that Melanie and all the rest of the programmers you can hire have been spending their careers becoming experts in.

Unit tests: Not going to say anything bad about unit tests, but they aren't a panacea or a guarantee that a program does everything it's supposed to do.

So, yeah. Times have changed. The standard stack is good enough for 99% of what you want to do now, as are the programmers that you can hire, and the costs of living outside of that ecosystem are high.[3] Still, there's something to be said for the other 1%, and I'll bet you there are still Mels out there kicking ass (not posting on HN), and I, for one, salute them.

[1] http://www.ultratechnology.com/forth2.htm (search for "documentation")

[2] http://www.gamasutra.com/view/feature/2985/postmortem_naught... (scroll down to the GOAL discussion)

[3] http://www.gamasutra.com/view/feature/2985/postmortem_naught... (right at the top)