Friday, April 15, 2005

"Inexcusable" failures of technology

David Berlind at Znet has listed his opinion of "Technology's 10 most inexcusable failures". His insights are valid, but I think he's missing the bigger issue.

He cites problems like "why doesn't my phone automatically remember a number I get via 411?" and "why can't my email system automatically read contact information from emails without an a priori, standardized format like vCard?" The complaints have a common theme: the user thinks, "why doesn't it do this very logical thing?", and the technology provider looks at the technology and thinks "given what I already know how to do, this is what I can do".

When the user says, "What I really want is to have my email automatically pull website addresses out of mail messages," the programmer's initial reaction is to write some code that pulls "http://" out of mail messages, and ship it as a feature.

Great--it did just what the user asked for. But what the user really wanted was "how can I make my email program and my browser share a brain?" The developer's logical but incorrect response leads to surgical, limited, and frustrating "fixes" for life's problems.

An example: Microsoft introduced the Start menu in Windows 95. They found that a large segment of users didn't know where to begin without Windows 3.1's visible Program Manager, so they added an animation that slid across the taskbar and pointed to the Start button. They correctly reasoned that the animation would get annoying after seeing it a few dozen times, so after the user uses the Start menu a few times, the animation no longer occurs.

The close-up problem is "how do we tell new users to use the Start menu, and then stop telling them when they know how?" The surgical solution is a bit of text, a chunk of code, and a Registry setting.

Later, they discovered that people who wanted to get rid of the Office Assistant altogether typically just hid it every time it came up. Another close-up problem, with another close-up solution: if you hide the assistant right away several times in a row, it asks if you really want to get rid of it permanently. Another small chunk of code and a Registry setting.

These are really two examples of the same problem: help the users until they don't need it anymore, then go away. But we keep solving the specific problem again and again, each time we see it come up, with specific one-off fixes.

On the other hand, after seeing this one too many times, the programmers bring out the big guns: they design a large, rigid, all-singing, all-dancing specification that attempts to predict and address all possible isomorphs of the problem.

Dwight Eisenhower is credited with saying, "If a problem cannot be solved, enlarge it." I'd add, "Enlargement is a strategy—not a goal!"

This is COM. This is OLE. This is MFC's document architecture, the vCard spec, J2EE and every other "boil the ocean" design that aims to enumerate all possible needs and create a design that addresses everything in one perfect system. It solves the original problem—sort of—and then acquires a life of its own. Now, when a different problem comes up, the programmer tries to force the solution into the amazing problem-solving framework. This works great if the new problem is truly identical to the old one. That's usually not the case.

So, instead of solving real, root problems in a sustainable way, we continue to choose between doing as little as we can to solve the facet we're staring at, or by designing a massive architecture that's too fragile to adapt to the next challenge that arrives.

The first person who understands this, addresses it in a way that adapts to new challenges instead of trying to predict them, and then packages it in a useable and attractive form, will be a true pioneer.

No comments: