I’m Old, Part LXIX: Nearly The Worst Golfers

When I was a youth in New Jersey, I played golf from time to time as it was a fairly cheap way to spend an afternoon since the county courses had youth rates. My dad got me my own set of clubs, a serviceable set. Playing at my best, I could manage bogie golf (1 over par on average).

Adobe, for a number of years, ran a golf tournament that I had always intended to play in, so one year I brought it up with some of the other engineers on the Acrobat team. I roped in Mike Pell, Mike Diamond, and Alan Wootton. All of us had played golf previously except for Alan. We went out to a local 9 hole pitch and putt to see what Alan could do and to see how rusty the rest of us were. We were all pretty bad. The only two things that I remember that were remarkable from that practice round:

  1. Alan consistently hit worm burners. Nearly every shot was straight as an arrow but hugged the ground.
  2. I landed a shot into a water hazard and rather than take the penalty, I waded in up to mid shin since I could see my ball and managed to hit it back onto the course.

(from left to right, Mike Diamond, Mike Pell, Alan Wootton)

We were pretty happy with Alan’s golfing because the tournament used “best ball” rules meaning that on any given shot, the team picks which shot they thought was the best and everyone takes a shot from that point to continue on. It makes the game somewhat faster, but in our case we could count on having one person who could hit the ball straight.

Then Mike took Alan to a driving range near Adobe. Mike taught Alan to hit the ball in the air instead of on the ground. And he also taught Alan to slice. Just like the rest of us. Damn it. For what it’s worth, I play left-handed so at least one ball would end up on the other side of the course.

We were terrible. Absolutely awful. We all spent lots of time in the rough. Mike Pell was the king of the Mulligan from the tee. Mike said “You guys don’t mind if I take that again?” several times on the course. On the last hole, Mike Diamond got way under the ball and it hit a low tree branch and rebounded and landed behind him. Many times we weren’t playing best ball but least worst ball instead. In the whole game, I think I only had one good shot, which was on a dog leg with some trees at the bend and some water, I think.

I went last, if I recall correctly. Mike Pell had the best shot at this point which was a little shy of the bend. Since we had something to fall back on, I aimed for the trees and put everything I had into the shot and I cleared the trees. At least I think I did, but nobody believed me. We picked up bags and headed to Mike’s ball, which we took as the next shot, which was a shame because I found my ball further up in a decent lay. Oh well.

In the end, we came in second to last, but not by much. We were truly terrible golfers to behold.

I’m Old, Part LXVIII: It’s Hard to Be Easy

“It’s hard to be easy” was one of the mantras of early Macintosh UI design. The notion was that in order to write an application that was intuitive took a great deal of iterative design and work. I bring this up in the wake of the awful, erroneous missile launch warning issued in Hawaii recently. Preliminary information indicates that the first few why’s in the 5 why analysis are:

A warning for a ballistic missile launch went out.


The operator selected the wrong menu item.


The two options, test warning and warning were adjacent to each other.


There was no confirmation box for the more dangerous path.

It reminds me of a situation that happened at Bell Labs in the 80’s, although certainly not so dangerous or so grave.

There was a cool type of terminal called the Blit (the one above is a 5620, a successor to the Blit with a different processor). It had a 1 bit display the size of a legal sheet of paper and had a resident 68000 microprocessor. On its own, the Blit was just a dumb terminal, but you could download programs to run on it including a windowing program called mpx which could multiplex communications to the host computer as well as run separate programs. Mpx was written primarily by Rob Pike.

One of the problems/features of mpx in the initial version was that there was no way to exit it. Once you started mpx, that was it until you turned off the Blit.

I should point out that I’m going on my own memory of being told about these events. If there are UNIX people who want to correct/amend this, please by all means do so.

My understanding is that users complained to Rob that there was no way to exit. Rob’s response was apparently typical Rob, “Why would you ever want to exit mpx?” He put in a menu. The problem was that it was the first choice in the menu and if you nudged the mouse button, it would select it and dump you out of mpx.

This is much less devastating version of the Hawaii bug: damaging UI actions should be protected by at least confirmation and shouldn’t be easy to initiate by accident.

Users complained: “now it’s too easy to exit mpx. Make it harder.”

Rob removed the menu and created an application called exit_mpx which would ask you a “hard” UNIX trivia question and if you got it right, it would let you exit. When I was in high school, I found this response to a user request hilarious. It was like a djinn granting a wish. Yes, he granted their wish but not in a particularly thoughtful way. That will teach you users to not to fully spec your wishes!

I don’t recall that this was ever changed. I learned a few of the questions and just reran the program until a question I knew came up. My favorite being, “how many pieces was Ken’s deer cut into?” (3)

Jokes aside, the missile warning issue is the kind of thing that should have been addressed in the specification if not the first UI mock-up. This is not entirely a trivial problem though. Upon the first indication of an in-bound ballistic missile, there’s something like a half hour until impact. That means that 1.4 million people need to get to shelter in that time so I can understand why the action is unguarded: make it quick and accessible, but this weekend’s actions have shown us that this is wrong. How much of a warning is enough to make it quick but can remove false negatives? A box that says, “You are about to send the following message to all of Hawaii. Continue? OK/Cancel”. Put in a check box in the warning that needs to be checked like a EULA before OK is an option? Put a divider in the menu? Move the actions to two different menus? User testing for sure.

At any rate, I would like to read a full 5 why analysis on this one.