February 10, 2006

What computers know can't help me, most of the work is mine.

I'm always finding myself expecting more from computer systems than they can deliver. I should know better, but I'm constantly being fooled by interfaces, by dialogs, and sometimes by the results. It's easy to think that Google actually knows what I'm looking for when the first result satisfies my query. But it just ain't so, and that's both important to me and irrelevant to the computer.

Orcmid and I have been having a long, slow conversation about computers, computation, and what we need to know as programmers and users of computers. What do we need to know about users and uses? What do we need to know to write useful computer programs and build usable systems? What might we rely on the computer application to know, if anything?

In a recent post Orcmid describes a simple thought exercise to illustrate what computers know, and what we need to know about that in order to write programs and to use them. In one tidy diagram and two short tables he captures the essential operation of stored program computers and the programs they execute. It shows what the computer knows, and what programmers can tell it. The key take away (that many of us already know oh so well) is that computers, and more specifically computer programs, know precious little, and they have no way to know about me, or why they are executing instructions, or what happens to the results that are produced, or what the heck the inputs are about. That's what I know, and what I need to keep in mind, when I use computers and when I program them for others to use. The computer can do lots of work for me, but the context of that work, that's part of my work.

My part of the work. This is exactly what everyone who uses computers needs to understand. No matter how fancy the interface, or natural seeming the dialog, or even useful an error message, you can't be fooled into thinking that the program knows what's going on. ATM withdrawal? The software has no idea about banks, money, deposits, or withdrawals (of any kind). I push buttons, the ATM program follows instructions and presto, there's $40, just the amount I selected. It's pretty neat, I'm off to grab lunch. From the perspective of the ATM program any relationship of the executing software to my world, like helping me get money so that I can buy lunch is purely and completely a coincidence.

All the utility and convenience of an ATM program is what I make of it. If I would only remember this more often then I might be less upset when a computer program asks an inane question, like the "OK?" that often follows a system or program error. Why should I expect anything but inanity in a dialog with a computer program. Why indeed.

Orcmid's post is a gem and worth a careful reading by programmers and users. By admitting just what computers know, maybe we can start building systems that avoid pretending to know more than is possible. We can start educating ourselves about how much we bring, and need to bring, to the interactions. We can stop projecting personality onto these machines and start asking for realistic and confirmable experiences. We can demand that the programs we write don't fool us into thinking they know anything about our world. We can demand, at the same time, that they be useful, usable, intelligible, and their actions verifiable.

More to come ...

[UPDATE: 2007-03-02: needed to change the link to orcmid's post.]

Technorati Tags: , , , , ,

Posted by Bill at February 10, 2006 8:35 AM