The book drew on my experience as a developer and user of groupware, which I defined simply as technology that helps people work together more effectively in information-rich environments. At the time, such technologies included NNTP newsgroups, web conferencing and the precursors to today's web services.
The landscape has changed since then. The term “groupware” has lost much of its currency while the trendier “social software” moniker continues its ascent. NNTP newsgroups have likewise fallen out of fashion. Nowadays we use weblogs to have loosely coupled conversations, along with instant messaging, Wikis and comment threads within blogs when various degrees of tighter coupling are needed. And we use web services to compose loosely coupled software systems in ad hoc ways.
One thing that hasn't changed is the nature of collaboration. Interviewed for a recent New York Times story on technology and productivity, former Xerox PARC (Palo Alto Research Centre) director John Seely Brown cited one key ingredient of effective teamwork: fluid improvisation.
"In soccer there are some set plays," Brown said, "but the best teams also display a wealth of effective improvisation based on the players' deep knowledge of one another. It's the same in the best corporations or startups."
I am sure that networked software systems can support and amplify that improvisational dynamic, but I often wonder whether our current software development culture can produce such systems. Consider the recent crop of six-degrees-inspired relationship amplifiers, notably LinkedIn and Orkut. Both have tin ears for social nuance. On LinkedIn, when asked to endorse a marginal acquaintance, I was stopped dead in my tracks by the requirement to define our relationship as one of a list of choices such as "You managed X directly" and "You were a client of X's." On Orkut the choice is even more starkly binary: "X is my friend" or "X is not my friend."
LinkedIn's and Orkut's tin ears shouldn't really surprise anyone. Social software systems are created by programmers who -- let's face it -- are not renowned for their social skills. A 1991 Wired article entitled “The Geek Syndrome” proposed a neurological explanation, highlighting an alarming rise in Asperger's syndrome in Silicon Valley. Whether you buy that theory or not, it would be hard to argue that social adeptness historically has been linked to advancement in the engineering ranks.
Another reason is even more awkward to discuss: gender. As everyone who attends conferences for programmers knows, the male-to-female ratio at these events is dramatically more skewed than that.
"I feel like I'm at a Microsoft monastery here," wrote Rory Blyth from the most recent Professional Developers Conference. "I think I've seen about 2.5 females ... it's like they're an endangered species."
The observation holds equally true for open source conferences.
Brown's soccer analogy doesn't (yet) conjure up an image of a co-ed team. None of our usual sports metaphors for business teamwork invokes the “female” traits -- real or stereotypical -- of empathy and social cooperation. If we expect social software to help rewrite the productivity equation, social skills and protocols become critical parts of the game. How can social software succeed if, in its development, half the population is so poorly represented?
Udell is lead analyst for the InfoWorld Test Center.