John Vlissides

John Vlissides died November 24th. A wiki page is dedicated to his memory.

One of my favorite books is John’s Pattern Hatching. I love that book. Reading it is like conversing with a wise, witty, insightful friend. As parting advice in Pattern Hatching, John advises pattern writers to,“ Write clearly and unpretentiously. Favor a down-to-earth style rather than a stuffy academic one. People understand and appreciate a conversational tone, making them more receptive to the material… Make sure everything you write is something you could hear yourself saying to a friend.”

Good advice. When I asked John to write a forward for our design book I was anxious about whether our writing and writing style would pass muster. They did (whew!). I was stunned by his generous, kind, and encouraging words. John has been a good and wise friend, mentor, and colleague, who has encouraged and inspired many in the software community. We will miss him very much.

Exceptional exceptions

I should have known something interesting would happen today when I read my horoscope*:

Chug along as planned. Circumstances might create a series of minor emergencies that interrupt your routine. Remain fluid about plans.

Today I had a bizarre ATM experience. The machine gobbled my deposit envelope but kept beeping and prompting me to deposit the deposit envelope in the slot. But I had already made my deposit! So after 30 seconds of incessant beeping I pressed the cancel button. The beeping didn’t stop. I calmly walked inside spoke to a teller (we could hear the beeping inside the bank). She walked outside, looked at the screen, and followed instructions inserting an empty deposit envelope. The ATM then ejected my card and a receipt that indicated my transaction had been canceled. But the machine still had my deposit envelope.

After a short consultation, a more senior teller took over. She opened the back of the ATM, opened the deposit box, and sorted through the envelopes. My deposit envelope wasn’t there. She closed the machine (meanwhile as she was doing this someone else successfully made a deposit that landed in the deposit box). She went inside, consulted someone in a back office, made a phone call and then spoke with me. She had reached someone who she said was “a little unreasonable”. They suggested I file a dispute and then they would schedule a technician to search for my missing deposit envelope lost inside the machine. Meanwhile she rechecked the deposit box, took my name and phone number and said she would resolve this today. And she did. A technician came out, popped open the front panel of the ATM, and found my deposit envelope clinging to the top of the dispenser in a way that allowed other envelopes to slide over my envelope and drop into the deposit box.

My thanks and gratitude goes out to that persistent teller. Without her my deposit would still be in limbo.

What about the ATM? Could it have worked better? How could it have handled this really exceptional case? I am guessing that my envelope never was sensed (otherwise, how could the deposit slot still be waiting to accept an envelope). It was in limbo. But beeping a long time while displaying the “insert your deposit envelope in the deposit slot” didn’t help me out. Those instructions didn’t apply to me! The fact that a teller could insert a blank deposit envelope meant the deposit slot was working; the next depositor’s actions confirmed that. But somehow my deposit envelope hadn't been recognized by the machine.

What about the behavior of “cancel”? Cancel didn’t mean “immediately cancel”. The machine kept incessantly beeping…demanding that an envelope be deposited. I was too stunned to know what it wanted. Even if I had figured out what it wanted, I don’t think putting in a blank envelope would’ve been a good thing to do. I can imagine the bank then claiming that I’d deposited an empty envelope and I probably would have had to file a dispute. In hindsight, my actions were the right ones to take. If cancel had immediately ejected my card, things might have been better… there was something disconcerting about cancel not having an immediate effect, even though it led to me going inside to find smart people who eventually tracked down the problem. It seems like a poor system design to have cancel wait until a hardware initiated action was complete. This could’ve been a result of poorly designed hardware. I just don’t know enough to say.

If cancel had been immediate, my card and a canceled deposit transaction would’ve been ejected. I still would’ve had to deal with the missing deposit envelope. But I suspect the story I told the teller wouldn’t have been so compelling.

The teller said that after a certain amount of beeping the ATM would have canceled my transaction anyway and swallowed my card (so this leads me to believe that there is some ability for the system to time out if expected hardware actions don’t occur). I still suspect a software bug. If the ATM had swallowed my deposit envelope this way during non business hours I suspect I would’ve stood at the machine until it stopped beeping …which would’ve led me down the same path but with undoubtedly more trouble. Hm.

As someone who has written many use cases, I would have specified that cancel should be immediate and that user transaction’s abort as soon as the cancel key was pressed (unless the transaction was beyond canceling and then some indication of that failed response signaled to the user). And then I would’ve written tests to push on all the weird cases I could think of.

How cancel is detected, when it should take effect, and what should happen often fall into that gray unspecified area. Most use case descriptions ignore or say very little about canceling actions. Specifying cancel exception behavior doesn’t fit well neatly with tying exceptions to specific use case steps since cancel can happen at many different places (and across many different use cases). Aren’t use cases best when they describe business-level steps, not lower level implementation details? Sure, but sometimes it is important to specify these pesky interaction details that make your system be responsive or react predictably.

My advice: when you want to specify these things, start by writing statements that describe when cancel is enabled (and when it is not), when the software should detect it, what should happen, and what should not be allowed to happen. You may need to define invariants that must be preserved, describe detailed cancel actions, or develop state models. These descriptions, in addition to use cases can specify interaction design. It’s unrealistic to squeeze every little detail into a use case description.

*Disclaimer: On the rare day that I read my horoscope I forget it by the time I’ve finished reading Dilbert and Doonesbury. But today’s horoscope was strange enough that I remembered it.

Customer service that works!

It is passé to rag on poor customer service. So I won’t. Instead I’m going to praise Interlink Electronic’s customer support. A year ago I purchased a remote pointer from Interlink. I wanted to use it on my new tablet pc. Plug-and-play didn’t work…and I went to their website to read the manual which directed me to “press the laser button and direct the beam on the receiver’s starburst pattern for 5 seconds” to re-program the device. “When the green light glows steadily the receiver is programmed to the unique address of the RemotePoint Presenter Remote. After address is established, the LED will return to blinking green.”

There was no starburst pattern on the receiver and no matter how long I shined the laser on it, nothing happened. So in a fit of inspiration I sent an email to their tech support. The next morning I received a reply that said that “my device should require no reprogramming to get it to work”. But still it ended with a polite, “are you having problems with your remote?” I replied that yes, I was still having problems and it didn’t work. Within an hour I got a very clear email:

Try this procedure for re-training your receiver:

1. Disconnect the receiver from the USB port and wait 10 seconds.
2. Reconnect and once the LED starts to flash, position the remote no more than a foot away from the receiver.
3. Press and hold the right arrow on the remote for about 15 seconds. You should see the flashing LED on the receiver turn to solid green, then red and back to flashing green.
4. Your remote should be good to go.

And it was. I even sent another email asking for access to downloadable software that lets you reprogram the device and I got another quick reply. I could rag on Interlink’s out of date manual or plug-and-play equipment that wasn’t. But I won’t. Because their customer service (thanks Ody) was so responsive. Helpful customer service. Imagine that.

OOPSLA, Creativity, and Practice

I’m home for 2 weeks after spending a week at San Diego at OOPSLA and last week teaching object design. It is good to be home as I can now configure my new tablet PC and start using it. It’s bad to be home as it is raining too hard and spoiling my plans for getting my perennial garden in shape for the winter. But truth be told, the rain leaves me hunkered down inside…forcing me to write, to reflect, and start new projects.

OOPSLA this year was full of creative types—George Platts led a number of workshops and experiences; Robert Hass, past poet-laureate of the USA, gave the keynote. This was no surprise with Dick Gabriel as program chair. Dick is a man of many talents. In addition to his heavy-duty computer side—having made Lisp implementations practical being one of Dick’s early accomplishments—he is a published poet, musician, patterns instigator, Sun fellow, and scholar. A highlight for me was getting Dick to autograph his new book of poetry Drive On and then to read it on the plane ride home.

Sunday morning I attended the tutorial, “How has the arts, sports or life stimulated, inspired and informed your work in computer science?” led by George Platts. George is an artist and game master who is a well known creativity/fun instigator at software pattern conferences. As it was a Sunday morning tutorial, I expected George to drive (and me to sit and quietly soak up his words). Silly me. After showing us an incredible film of an amazing panoply of pyrotechnics, mechanical feats, oozing chemical reactions crafted to produce a Rube Goldberg-like perpetual motion machine…we sat down to discuss how art or sports stimulated or inspired our work.

Two thoughts struck me about how arts and sports have stimulated my work. In college I fenced (with a foil—don’t ever call it a sword). Much preparation went into a competition. We repeatedly practiced standard moves (all with Italian names). Only after much practice with attacks and counter-attack moves would we do practice competitions. Being a left hander gave me a distinct advantage as my body was not where it was expected to be. Lefties fencing lefties are on equal footing as we, too, are accustomed to fencing right handers. So even while I was at an advantage (being short makes for a smaller target and being a lefty makes for an unusual target) during the heat of a competition I’d forget much and just go on raw instinct. Only when moves and countermoves become kinetic memory do you get really good. I never got good as I spent too much time getting my programs to work instead of devoting energy to perfecting my fencing technique.

Bringing up this notion of practice led us to discuss what constitutes “practice” or “repetition of scales” for software developers. What do you developers or designers or analysts do over and over and over again until it becomes second nature and makes them good at what they do? Programming? Applying design patterns? Writing use cases? Learning how to ask probing questions? Well maybe. I’m not sure we software types have a clear equivalent of scales. Does repeatedly programming yet another JSP make you a better at it? Building consistency into your design makes your design better. But does it make you a better designer?

A second artful inspiration I’ve had is from Betty Edwards, author of Drawing on the Artist Within. Betty has inspired me as a teacher of design in how I try to break down design ideas and thinking for others. Betty claims that people are crappy artists because they don’t know how to see…and that by learning special ways of seeing, most of us could be able to become passable renderers of what we see. She believes everyone can be taught how to draw likenesses of what they see. I had a really bad pottery teacher in college who asked us to “feel what was in the clay and then create”. I was frustrated and created lumpy awkward pots because I lacked technique and this instructor didn’t teach any. As a teacher of design I don’t like it when my students create lumpy malformed objects. I teach them a number of techniques for seeing good formations of objects—role stereotypes, a smattering of patterns, the notion of domain entities and value objects from Eric Evans’ writing, a sense of control style choices. But sometimes these ways of seeing don’t click in and my students create strange designs. Or worse yet they get frustrated and just want to know what steps to go through to create passable designs—to heck with all this technique. All I can say is that design takes practice and reflection and technique. I don’t know how to teach design as a rote process.

As a result of George’s tutorial, I got to know Henry Barager of Instantiated Software Inc. Besides being a skilled software architect, Henry’s a whiz at cryptic crosswords. Over lunch one day at OOPSLA Henry taught me about cryptic crosswords by working through one with me (Henry did most of the work but he patiently let me solve a few entries after explaining the basic idea). The key to solving a cryptic crossword entry is to figure out how to separate the word or word phrase you are solving for from the encrypting part. Then there are clues in the encrypting instructions part which may lead you to take some letters and jumble them (key words may imply that you create an anagram, wrap one word inside another, truncate a word, etc.) or not. For example: Flower came up. The answer is Rose. Rose is a flower, and “came up” is another meaning for rose. Simple, right? Well try this: Piece of technology in broken device tossed out. Give up? It is evicted (tossed out = evicted, that’s the definition. The rest of the encrypting part is this: A piece of technology is the “t”, broken device is “evic ed”—jumbled or broken).

Explaining the idea behind cryptic crosswords is fairly simple. Solving entries takes a lot of effort and getting your brain in a problem solving frame of mind. Solving them in real time as Henry does requires skill, experience, and intelligence. Teaching others how to solve them takes another kind of skill. The same goes for object design. Learning object concepts is trivial. Crafting simplistic solutions is, too. Putting together elegant designs that work for complex problems is much harder. It requires practices, reflection, as well as learning techniques from masters—who shouldn’t try to solve all the hard problems for you. I wish I’d had someone who would’ve demonstrated and helped me practice good technique when I was learning to shape pottery or to draw. I was fortunate to rub shoulders with some very bright Smalltalk folks when I was learning how to think in objects. Thanks to all the folks at Tektronix and Instantiations for teaching me how to see and build object designs.