Rules for Systems Programmers

Rule #1 – Never check for an error that you don’t know how to handle.

I don’t know where I learned this one [probably some fortune cookie file], but it’s sure useful. Better to crash horribly than write a lot of recovery code that you can’t test. Or just silently reboot; nothing gets more mysterious than just going to high IRQL and passing control to the power-on handling code.

Rule #2 – If you must crash, blame someone else.

For instance, once you discover that your custom transactional file system update locks deep in the kernel have been completely borked by a page fault or maybe heap exhaustion, arrange for someone else take the heat. For instance, set things up for X Windows to blow huge gobbing chunks long after you’ve swept up the evidence, pretended everything was hunky-dory (“Ming vase? What ming vase?”) and returned (… walk away slowly in any direction, hands in pockets, whistling tunelessly).

“Man, X just keeps blowing up on me.”

“Yeah, I thought it was the file system locking, but it looks like the old X clipping problems are back. This release is the worst ever.”

Rule #3 – Misdirect, misdirect, misdirect.

“Hard crash? Okay, send me a dump file.”

later… “Oh, that dump was corrupt, can you send me another using the latest build?”

later… “What processor are you using? A Zorxlon? Oy, they’ve got notorious bugs in their cache replacement, and when they get hot the content-addressable memory leaks like mad. Can you swap it out? Wimptrons are good, I hear.”

later… “There’s no way this GUID came from any of our machines.”

Rule #4 – Sure you can have that!

Someone comes to you with a feature, X. “We really need this in the next release. It’s a heavy customer ask.”

Now is the time to find some all-inclusive universality about X. From there you can either show how that feature already exists in the system (well, sort of…), or you can demonstrate how hard X is to do (it’s been the subject of research for 30 years, it’s going to take a ton of work in the most critical parts of the system to do “right,” the corporate research group has written some papers on it, why don’t you read those…).

Or, it’s story time: “We tried that before in a prior release and it was a disaster.” Blow, wind, and crack your cheeks, right down to the ball lightning, losing four sailors off the poop-deck, the white whale with an attitude, and the snapping of the main-mast just before the jib exploded.

Or, you can say, “Well, we’ve been working on something pretty similar to that, it’d be a shame to waste that effort, let’s see about including X in the effort on Y.” Naturally X now threatens Y; this is remarkably useful when the people doing Y get properly territorial and uptight about including stuff that maybe doesn’t belong there after all. On a good day you can start the bar fight between the asker of X and Project Y, then get out of the way and enjoy the carnage.

… more coming … 🙂

This entry was posted in Rantage. Bookmark the permalink.

One Response to Rules for Systems Programmers

  1. Kim Toms says:

    I wrote a program (about 30 years ago) for doing what “cu” or “kermit” did between vaxes. When it got a QIO error it didn’t understand it’d print “big error number 2”. People still kid me about that.

Comments are closed.