By John Kehoe - 28 January 2009
I do not like change forced by ‘the Man’, change out of my control or change that doesn’t help. I do like change that I push, change that makes my life easy and change that puts money in my pocket. As IT professionals, we push change. We often do so without appreciating what our users require, what the users are doing or the historical context of our solutions.
What are we doing wrong? Let’s look at a manufacturing example. I once owned a nice little under-the-cabinet toaster oven, circa 1991, that worked reliably for almost two decades. When it hiccupped I simply fixed it. Alas, it eventually started belching smoke and so I replaced it.
In the IT world, this belching represents the old, unsupported application that we are afraid to touch, lest it combust. It has exceeded its carrying cost and the time has come to replace it. My quest to find a new toaster oven took a while as the new models had been redesigned to meet current codes (think the manufacturing equivalent of SOX, HIPAA and whatever the politicians are about to do to the financial sector). My Elbonian made Char-Nobyl 8000 toaster oven, finally arrived (long past due, as often happens in software system replacement). We had to measure and mount the heat shield as well as mate the oven to the mount (application infrastructure). The instructions turned out to be wrong. I could not reuse the existing mounting equipment. Matching up the supplied components was problematic. Poor design, poor build, poor execution and dodgy installer.
Now we get to use the oven. My first thought: why is my toaster oven plastered with English, Spanish and French instruction and warnings? I bought it in Chicago, not Paris or Buenos Aires. This is the small electronics world equivalent to the user interface. It’s annoying (sure I’m ethnocentric, but a Frenchman and Argentinian would say the same: they didn’t buy a toaster in Chicago).
Now I want to toast a bagel. Simple task: insert bagel; set darkness; start the job; repeat as desired (or ‘insérer bagel; set obscurité; démarrer le poste de répétition comme souhaité’). It’s not that simple with this toaster oven. This baby comes with a plethora of dials. First you set the darkness level. Then you rotate a knob clockwise, then counterclockwise. The third step is to wait for the light to turn green (which, for some reason, turns blue instead). Finally I push the button to ‘launch my bagel into orbit’. Success! I toast another and it’s burnt. Turns out I need to recalibrate my darkness level with each toasting to avoid burning. At least it doesn’t belch smoke.
This is a good metaphor for the weakness of IT applications: we toss in every conceivable feature, the UI is unnatural, the instructions are off, the business rules are mercurial… you get the idea.
How do we make a better toaster oven? Consider the past and the trade-offs. Do we need to replace the heat shield and mounting locations? Can we at least use the same bolt layout? Do we need the languages? Do I need this degree of globalization? What about the UI, why have the extra dial? Why can’t the oven maintain a regulated temperature? In IT we tend to design what we think we need, not what our customer needs.
Asking the customer is no guarantee of success. We’re still likely to end up with dozens of ideas, many of them contradictory or just plain bad. A few gems may exist among amongst the cruft, but they are sometimes difficult to distinguish. We may even avoid considering customers or users who have a propensity to complain.
So where does that leave us? We must look to the past. Just because an idea is old doesn’t mean it’s stale. Consider this story in the context of today’s web 2.0. In the late nineties, I worked with Digital Equipment Corp (DEC) systems. I once chatted up a DEC field SE about the reliability of their hardware. He proudly told the story of a 911 emergency system that had been running on a VMS (a real operating system) cluster (DEC invented the technology) for 16 years with zero downtime. The design was thoughtfully centered on what the user required and what the technologist could do. Yes, they periodically refreshed the software and the operating system. All this was done without bringing the application down. Try that with today’s technology mix and applications. Would you want a 911 system running on a cloud or web 2.0?
Here’s another example. Remember the really cool chairs in the 1960’s sci-fi movies. In all our sophistication, we mocked the strange designs. Surely they had to joke (OK, they were being serious, but the design did not age well) that anyone would use such a contrivance. Well forty years later, I’m at a state of the art (opened three days earlier) corporate video conference center for a $34b company. What’s the first thing I noticed, after the three HD armed cameramen and thirty foot projector setup that put IMAX to shame? I see these wild-looking chairs that could have come from 2001: A Space Odyssey or Logan’s Run.
So what can we glean from my tales? First, the problems we see today have analogues in the past. A lack of historical perspective in our current crop of technologists hampers good problem solving (Action item: crack open a VMS manual to steal some ideas). Two, our solutions are too often divorced from the use case. Our users are not forthcoming in what they want nor do they fully appreciate what they need. We must crawl into their heads to understand what is required and build from those use cases. I say use cases deliberately: we don’t need pretty interface ideas. We do need to value the UI, but we can't simply put out something shiny and think that's the end of it. Form must follow function, which means we must first understand the function. We need to know how they do their jobs today and how the tool we are building will help them do it. Three, we are making software that is too difficult to use. Consider the toaster oven. Why the abrupt disconnect from the past? If your users are coming from 3270 terminal land or fat client world, our objective is to make lives easier with technology, not to simply require users to change from one technology to another. Finally, consider the plumbing. Are we proposing a more reliable solution than the customer has or are we opening ourselves to reliability and performance grief?
So crack open those old manuals, play with some assembly code and enjoy some classic sci-fi movies this weekend. On Monday you can start looking at use cases. By Friday you might be able to deliver some ‘change’ that doesn’t ‘look’ like change and make change resistant users think they came up with it.
About John Kehoe: John is a performance technologist plying his dark craft since the early nineties. John has a penchant for parenthetical editorializing, puns and mixed metaphors (sorry). You can reach John at firstname.lastname@example.org.