Wednesday, April 27, 2005

The recent influx of "name" talent at Google reminds me of the projections we used to make in the mid-nineties of how many years, at current growth rates, it would take until Microsoft employed all of Washington State (where I was living at the time).

Friday, April 15, 2005

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.

Thursday, April 07, 2005

Two firsts today: a first attempt at blogging from my new phone, and the first time hearing Richard Stallman speak.

Phoneblogging was easier than I had feared, although my phone insists I am clogging.

RMS spoke at Pitt. On the one hand I was a little disappointed in the content of the talk: I was expecting more "current affairs" and state-of-the-FSF, but the bulk of the talk was right out of Free as in Freedom. My disappointment was tempered about half way through the talk, when I realized that two thirds of the audience weren't alive when the events he was explaining occurred. The reactions from the crowd implied that for many of them, this was the first time they were hearing about the beginnings of the Free Software movement. The audience were roughly an even mix of free software cynics ("how can I ever earn a living if I give my work away for free?!") and free software advocates ("how will issue X affect free software?"), and a blessedly-small number of red-faced "oh-my-God-it's-really-him" fanboys.

I recorded the talk on an ancient minicassette recorder. It's not good enough to Oggify and put up, but I know some other people were recording; hopefully one of them will podcast it. He said a few interesting and new things--most interesting, he rattled off a list of a half-dozen or so changes that are being discussed for GPL 3, some of which I haven't heard before.

The question-and-answer period was fun. When I introduced myself as "one of the bad guys", who had the temerity to use Emacs to develop non-Free software, the room groaned, but Richard was gracious ("Using Free software to develop non-Free software doesn't make it any worse.").

What struck me most was his honesty and surprisingly, his humility. That's a word I haven't previously associated with him. He acknowledged when people pointed out "grey areas" in the philosophy (for example, the dichotomy between free software and non-free content). Before the talk began, I wanted to snap a picture of him, and asked his permission. He looked at me, paused, and said, "You know, your freedom is more important than me. Go ahead, but I'm not the important one here."

Unfortunately, that picture is the only one my phone has munged so far. Fitting, given his statement.