Peter Coffee: Pioneering work is just the beginning of long journey to network services.When the New York Times reported Alan Kays arrival as a senior researcher at Hewlett-Packard Laboratories, my eye tripped over that articles description of Kays pioneering work with Smalltalk: "an influential programming language that uses blocks of code, known as objects, that are put together, like the cells that make up the human body, to build applications."
Ive seen many metaphors for object-oriented programming, but the comparison of objects to human cells is new to me--and my reaction is, "if only." The self-organizing properties, resistance to external threats, and ability to adapt to new environments that we see in the human body are excellent goals for distributed IT--but terribly distant from anything that we have yet produced.
HPs R&D shop has certainly hooked a prize catch in bringing Kay on board. Were talking about the alpha geek who envisioned the Dynabook, a personal system with hardware a lot like that of a Tablet PC, more than 30 years ago: the über-user who demanded tools that would help people think and create, rather than forcing people to descend to the level of the machine as the price of obtaining its assistance with rote computation.
Kay was one of the leading lights in developing the Smalltalk programming language, whose integrated tools and high development productivity made Digitalks PC version a major contender in several of our early (then-)PC Week programming Shoot-Out challenges. But make no mistake, using Smalltalk didnt make a mediocre developer suddenly smarter; rather, it allowed talented people to drive the machine as hard as they drove themselves.
As I said after watching one of Digitalks Shoot-Out teams correct a system crash on the fly, an experienced Smalltalk developer at work is like someone doing brain surgery on himself. The process puts incredible resources to work, but its not a fault-tolerant proposition. Its certainly not the self-organizing system suggested by the New York Times breathless simile.
In general, this is one of the problems with early reports on any new approach to application development: The people who are first to try anything new are often among the most capable and most motivated developers around, people who are capable of producing impressive results with an EMACS editor and an assembly-language compiler. And programming, as most famously observed by TRW researcher Barry Boehm, has perhaps the highest ratio of peak to average performance of any skill: at least 20 to 1. In fact, one of the first hard studies of this phenomenon in 1968 found a ratio of 26 to 1.
Its therefore vitally important to distinguish between the value of a programming tool or technique when used by the best in the business and its likely impact in the hands of a more typical development team. Web services, software agents and other intrinsically complex efforts risk disaster if this precaution is not observed. As Ive pointed out before, two interacting services or agents developed by one team are a demonstration; developed by different teams working for different organizations, theyre at best a negotiation and at worst a death-match confrontation.
Systems that interact across enterprise boundaries are about as much like a trade show .Net demo as a water polo match is like synchronized swimming.
When eWEEK reported on Kays arrival at HP, its not surprising that we offered a different perspective: "I agree with HP on the need to support standards-based, modular systems, where it makes sense for users and the industry," we quoted Kay as saying. Thats the beginning of the level playing field on which many different providers of data, services and other more concrete products can compete to offer value and to keep each other honest.
Without that environment, even Kays most fully realized vision of the Dynabook--not just the hardware, but the tools for collaborative discovery as well--will be trapped in a tiny subset of its potential. Until we reach that goal, its up to enterprise IT builders not to trap themselves.
Tell me what it would take to make a Dynabook out of a Tablet PC
IT Management 
