ToolRules

A friend asked me recently to comment on some candidate research and development projects that might help people make (more) sense out of huge quantities of disorganized information. I came up with some tentative "rules for tools" --- criteria that good knowledge discovery software must meet.

But first, an aside: for any tool to be truly useful there's a really hard problem that's not (very) technical: people --- developers, managers, and customers --- must collectively recognize the system which tools need to augment and enhance (and fit within, and help to evolve). Otherwise, technical/organizational/personnel fixes aren't likely to have any significant impact. By "system" I mean something in the Senge "Fifth Discipline" systems-engineering sense --- a set of feedback loops and delay lines and dashpots and actuators and so forth, to put it mechanistically. (see FifthDisciplinarians, 10 September 2000)

A few rare people understand this sort of thing --- generally from lessons that they've learned by having lived within a dysfunctional system for years. Most such tool customers, alas, aren't technologically savvy; contrariwise, most tool developers aren't sufficiently customer-problem-space savvy. Hence, among other recent catastrophes, witness so many dot-com silly shipwrecks, projects which ran aground when good technical ideas hit reefs of social issues such as privacy, security, inertia, data noise, etc.

But to answer the original question --- in general, good tools must:

• answer the simplest & most common user requirements efficiently (i.e., be optimized over the real-world problem space that users care about)
• run (and run well) on the customer's desktop rather than on a Xerox Alto, a Symbolics Lisp Machine, or other weird unsupportable box which the developer happened to build them on
• be cheap enough for everyone to afford
• have a decent user interface, one that busy non-specialists can learn in a reasonable period of time
• be open for data flows in and out --- at least via copy/paste, but if possible through UNIX-style pipelines or other standard interfaces, so that every tool "plays well with other tools" on the customer's turf
• never assume that input streams are noiseless, homogeneous, pre-tagged, etc.
• fail gracefully, predictably, and detectably (no surprises at a critical moment, please!)

Past attempts to deliver revolutionary tools often failed because:

• technology (both hardware & software) was too immature
• too much custom software development was needed
• the key data streams flowing in to the customers were too heterogeneous and ill-structured to be handled by computer tools (without excessive human pre-processing, etc.)
• management didn't understand the nature of the challenges
• too few people were able to "speak both languages" --- customer-world and technology --- to bridge the gap (chasm? gulf?) between the two worlds ... in other words, developers didn't "live" close enough to the users to properly understand (grok) their requirements, and contrariwise customers didn't properly understand the developers' constraints and capabilities (see IncommuniCoders, 29 July 2000)
• the best people (in both worlds) were spread too thin --- working on other tasks, putting out fires, saving civilization, etc --- to devote enough time & creative energy to the job
• the problem space was changing too rapidly and the information technology potential-solution space was changing too rapidly for large bureaucratic systems (customer or developer) to target effectively
• Extreme Programming methods hadn't yet been invented/discovered/appreciated (^_^)

On the brighter side, during the recent past there are real signs of:

• an increased desire by managers to break down inter-organizational barriers and (attempt to) share information better between "stovepipes"
• a rapid and major movement of people from less-urgent to more-urgent problem-solving areas
• a general increased helpfulness and shared desire to do something useful, quickly, on the part of just about everybody (see HomeDefence)

So there is hope....

TopicProgramming - 2001-11-10

(correlates: GoodNotation, FreedomPeaceCommerceEducation, UpsideDownShadows, ...)