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 … ūüôā

Rules of Thumb

Some more rules of thumb:

A firm with more VPs than bathrooms is in trouble.

Computer industry kiosks always, always suck. It doesn’t matter what they’re for (demonstrating a product, letting customers do downloads, whatever), they are always broken, out of date, messy, mobbed by antisocial teenagers or covered in gum and located next to the Slightly Used Printer Paper section of the store, where cockroaches and creepy old guys rummage through bins of used crap in search of deals they can’t understand.

Similarly, computer stores that don’t actually sell anything (remember Gateway Country?) are a sign that whoever is in charge of Marketing desperately needs to have their ass canned.

The only programmers who understand multi-threaded code are the ones who continue to wake up in the middle of the night in a cold sweat long after the product ships. “Did I remember to … ? Oh, yes, I did.”

A security system will be defeated with $200,000 of specialized equipment found only in industry labs and places like MIT. More advanced systems will be vulnerable to $20 spent on the right stuff at Radio Shack. Truly secure systems will fall to a bent bobby pin and a swift kick in the right spot.

Yes, it could be bad memory. A couple of times, it has been.

“It’s too simple to explain.”

Alls well that falls well

“A certain televangelist dies and goes to That Other Place –”

“Which place?”

“Hey, he gets there, to the other place, right, and everybody’s like, watching teevee –”

“What are they watching?”

“I don’t know.¬† 24, maybe the Simpons, whatever, okay?¬† It doesn’t matter.¬† Anyway, they’re all simply glued to this gigantic teevee they have hung up on the –”

“Is this joke going to be disrespectful?”


“It’s not worth it, man.¬† You just come across as yet another televangelist-hating elite geek creepoid who preaches to his own choir.¬† There’s nothing original in that.¬† Why even bother?¬† You’re making a joke about how some evil fat bastard finally got his.¬† What’s your point?”

“I guess you’re right.”

“He was a pimple.¬† He’s gone.¬† He’ll be replaced by someone worse, by and by.¬† That’s what your joke should be about, the conniving dirtbag who’s going to take advantage of even more people and screw things up way worse than they are today.¬† That’s who.”

“Okay.¬† I’ll work on it.”


“Dadddddy, there’s a chocolate tomato in the pretzels!”¬† (Holds up a crayon).

“Ummm . . . what’s it doing there?”

(Gets a serious expression, examines the crayon)¬† “Hang on, daddy.”¬† (runs off)¬† “Okay, bye!”¬† (Door slams.¬† He discovered doors a little while ago).

I think I missed some important context.



The Spagthorpe System/37 was …

Who am I kidding? There wasn’t any such thing. There wasn’t a mainframe that ran on 440 volt five cycle power, it didn’t make double use of its mercury delay lines for cooling, it didn’t use four-state logic in the ALU, the disk drives didn’t also work as washing machines for the system operators. There wasn’t a cot that pulled out from below blinkenlights on the front panel, there were no thudding relays that tripped whenever a program indirected through NULL by accident, divide-by-zero did not telephone the manufacturer and call a customer engineer in to replace the DIV0 fuse, and the main memory cabinet did not have a little seat and a small refrigerator inside so that salesmen could lurk for days on end, observing customers and their computing habits. There was no confettii option for the line printer, no way to make the tape drives spray multi-colored tape over the room or have the vacuum motors play tuba sounds, and you couldn’t re-route the B-supply line through the operator’s chair if you needed a new stack of cards put in the hopper. There was no spindle operation on the card reader, you couldn’t make the PC go backwards with a bit in the PSW, there wasn’t a way to power down the system and then bring it back up a few seconds later, and there was no secret instruction to make the disks spin backwards.

There should have been, but wasn’t.

Somehow, just sitting there and being a computer was sufficient.

Phone software ecosystems suck

This post (via reddit) pretty much sums up what I thought about writing software for phones.  Link.

To summarize:

  • Phone platforms are about as homogenous as a fruitcake.¬† If you thought that doing a Windows and a Mac version was bad, multiply by like twenty or thirty to get all the popular phones.¬† And no, Java isn’t going to save your butt.
  • Nobody is your friend.¬† Forget about making financial deals with the telcos, they don’t care.
  • Customers are stupid and lazy [with regard to phones, anyway], and won’t install your software even if they know how.¬† For the few that do, when they upgrade their phones next year, your software won’t be on them (have you done the port yet?).
  • Development environments will have you remembering with fondness the projects in the 80s when you used to blow sets of 256KBit EPROMs, and always had a few baking in the UV eraser; thirty minutes to an hour doesn’t sound too bad.
  • Batteries still suck.¬† (Phone engineers know how many electrons it takes to do an ADD.¬† “With or without carry?”¬† You think I’m kidding?)¬† Nobody is going to play your Quake port for more than ten minutes, because they can’t.

If there’s an answer here, it end-runs the telcos and their crappy environments.