This story came up in a conversation today, and I thought I’d post the link: The Story of Mel. Many years ago I made a little poster with a quote from this story:
If a program can’t rewrite its own code, what good is it?
I’ve kept it on my bulletin board ever since.
A similar story my father told me: the IBM System/360 model 30 implemented the S/360 architecture through microcode, and by changing the microcode it could also emulate an IBM 1401. This way shops that had a 1401 could get a model 30 and still run their old programs while they were rewriting them for the System/360: shut it down, switch the microcode, and restart it in 1401 mode. (And it ran those programs twice as fast as a real 1401.) The microcode was on copper-clad punch cards; the instructions were sensed based on the capacitance.
My father, who was an IBM Systems Engineer at the time, was working with a customer (I think it was Lockheed) that had customized 1401’s with an extra instruction. (Yes, back then computer companies would customize the instruction set on your computer if requested.) To use their old programs on their new model 30, they needed IBM to customize the 1401 emulation, so IBM flew out a microcode guru. He asked them what the instruction code was, and they told him, so he sat down, did some calculating, and said, “That would make the tape drive rewind and unload the tape.”
“Yes,” they said, “that’s what happens.”
“What do you want it to do?” he asked.
They told him, and he sat back down, did some more calculations, pulled some copper-clad cards and a hole punch out of his briefcase, punched a bunch of holes in the cards, and stuck them in the machine.
“Now try it,” he said, and it worked.
I think one of the more fundamental differences between programming now, and programming in the early decades of computing, is the approach to complexity. In the early decades, a person who was expert in computers could know them the way that early car mechanics knew cars. They knew it well enough to write something and, if they were careful, have it work the first time. They knew it more or less thoroughly. Modern car mechanics, of course, have access to a lot less of the car.
Now, good programmers know computers the way that a veterinarian knows animals. They know a lot, but it’s a small fraction of that which is relevant and important, and a lot of their expertise is in the form of trained instinct, which allows them to work around, or at least cope with, their ignorance of how a lot of the fundamentals work.
There’s probably some lesson to be learned about how programmers’ personalities and methods should resemble that of good vets now instead of good car mechanics, but this comment is long enough already so I’ll leave it unsaid. Plus, I’m not sure I have the personality of a good vet so it might be self-incriminating.
Really good analogy.
The biggest thing I see is that the software stack has gotten large, hard to understand, and at times even indeterminate (think thread-scheduling). Debugging skills become more and more important, but few know enough to really debug all the way through the stack, so we have to use various heuristics and simplifications.
We are gradually specializing to handle the burden of things to know (e.g., one person works on front-end stuff, and someone else handles the database back-end), but, of course, this makes debugging the whole stack harder than ever…