Building Subservient Systems

Can we build systems that do what people want done, rather than do it yourself tools?

There are some indications we're getting there. Autodesk has a product in its stable which may be the prototype of the 1990's application. I'm talking about CAD/camera. You take a picture and say ``go make that into a CAD database''. It goes and gives it its best shot, and you get to look at the result and change what you don't like about it, and teach it how to do its job better. Notice that of all of our products, this is the one people take least seriously because nobody is really confident that a computer can do what it sets out to do. Yet of all our products, it is the one most assured of success if it actually does a good enough job. This dichotomy characterises subservient products...look for it.

There is a database system on the market called Q&A from Symantec which lets you enter queries such as:

How many people in sales make more than $50000 in salary and commissions?

Which of them live in Massachusetts?

I am not sure that anybody will ever actually build an ``expert system'', but much of the work being done in rule-based systems is directly applicable to building the types of products I'm talking about here.

Although I have only recently pulled all of these threads together, I've been flogging products like the ones I'm pushing now for a long time (so I have a bias in their direction). NDOC is the second word processor I've built which attempts to do reasonable things with very little user direction. The first one obliterated its competition, even though it provided the user much less direct control over the result. In the world at large, the battle between and SCRIBE is being fought on the same ground.

When you encounter a subservient system, it tends to feel somewhat different from normal computer interaction. I can't exactly describe it, but try the ``Clean up'' operation on the Macintosh or the FORMAT command in Kern's editor and see if you don't understand what I'm saying.