People, Processes and Things

A product I worked on a few years ago had as its mantra: "people, processes and things". As a marketing message, the slogan's usefulness left a lot to be desired; the catch-all "things" seemed an imprecise cop-out at best. The product dutifully died a quiet death even if it is being reinvented these days. As a rough taxonomy of software applications however, the slogan was a serviceable description of the different areas we focused on. Software architecture is difficult to articulate in any case so fuzzy handwaving of this sort is the norm.

Two recent posts gave me cause to revisit these notions. The earlier one, from Barry Briggs, was a speech wherein he anointed this era the Decade of Process. The second was Jamie Zawinski's takedown of "groupware". Both are interesting takes on these different approaches to software.

On People

Writing in his ever quotable and blunt way, jwz packs a lot of insight into why it's a case of "Groupware BAD... Users Good".

On why people want to write software:

Our focus in the client group had always been to build products and features that people wanted to use. That we wanted to use. That our moms wanted to use.

Adam Bosworth similarly talked about the Mom factor in the design of applications.

More generally, he comes around to one of the pithiest definitions of social software.

So I said, narrow the focus. Your "use case" should be, there's a 22 year old college student living in the dorms. How will this software get him laid?...

"Social software" is about making it easy for people to do other things that make them happy: meeting, communicating, and hooking up.

There's lots more in this vein: why words like workflow or enterprise make his eyes glaze over, why groupware is an albatross, how that kind of software is not sexy etc.

The wider insight however is that Zawinski's argument is about focusing on people. It's a recognition that human beings are simply very social beasts and that we place a premium on communications. That's why phone, email and instant-messaging are the big applications of the day. When designing applications in this space, it's mostly a matter of getting out of the way and letting exchanges and interactions occur. Browsers and the web servers are some of the best software incarnations of this principle.

This focus on people, on connectivity and on simple communications is all part of longstanding historical trends in transportation and communications systems. This has been covered most fully by Andrew Odlyzko you can read him on read on why Content is not King, or more exhaustively on the history of communications and its implications for the Internet (pdf).

Among the core architectural principles of the internet are things like the "end-to-end" principle and internet transparency. I like to think of these as engineering tradeoffs in network design that are premised upon the virtue of connectivity. The network "laws" that apparently grow out of these design principles are things like Metcalfe's law on network utility or Reed's law on group-forming. These ideas embody more than mere connectivity however, and the software that builds on top of them is similarly diverse.

Once you move beyond simple person-to-person communications and information sharing, you get into what is the daily bread of those folks at CUE and Many-to-Many and begin to consider the ways in which humans organize themselves. You very quickly start talking about interaction trends in families, clans, tribes, groups and more generally about communities. This "stuff", the cement of society, if you like, is something that sociologists or anthropologists have greater facility in describing and something that software developers have, on the whole, done a poor job of translating.

When you consider how organizations operate there's lots that is implicit and most software has been a blunt tool where a light touch has been required. Just as an example, in most software, things have to be explicitly stated: I'm a member of this group, so-and-so is my friend etc. And even when software can infer or recommend things, oftentimes it is inexact and requires much fine-tuning and/or constant training.

If you take a wider view, you move from the realm of sociology and begin to talk about economics, about commerce, about capital and about ultimately about power. Once business and money comes into it, you understand that are vast quantities of software that address the needs of these other entities. It's obvious that not everyone will be able to write software like Zawinski has (Netscape) that has indeed changed the world and can be strictly focused on users, connectivity and communications. What makes users happy often doesn't coincide with what makes businesses happy - and as for the matter of motivation of software developers, the most salient fact is that businesses tend to pay large and regular amounts.

On processes

I'd argue then that the picture is wider one than simply "people" and that's where I'd return to Briggs' piece on processes. I didn't know Briggs when he was at Lotus but it's clear that we've drunk from the same Kool-Aid: I've used similar examples as he in presentations in the past year, working as I am on forms technology, namely:

Five thousand years ago on Crete people wrote documents in a script we later termed Linear B. When Sir Arthur Evans at the turn of the last century unearthed the tablets at Knossos, the world wondered at them, but for decades could not read them. Then, in 1940, a British scholar named Michael Ventris announced to the world that he had, in fact, deciphered the tablets and that they were in a form of archaic Greek

The world held its breath. Were they previously unknown epic poems, like the Iliad or the Odyssey? Were they great plays by some long-forgotten ancestor of Sophocles or Aristophanes? Were they philosophical discourses by a forebear of Socrates or Plato?

No. They were lists. Lists of sheep. Cows. Horses. Slaves. What we would call today inventories, bills of lading, invoices. To our chagrin, we realized that then, at the dawn of history, these citizens of archaic Greece -- like those of Sumer in the Fertile Crescent of Mesopotamia, like those in Egypt -- lived in a rigidly bureaucratized dictatorship.

They were empires of accountants.

Why do I recount all this? Because our little tale highlights something important, which is that commerce, trade, and the documents that record them lie at the core of the human essence. We are creatures of commerce; it is innate to the very notion of humanity.

Brigg's point is that even though we have wonderful things like literature, it is likely that the invention of writing systems was prompted by mundane bureacratic concerns. He goes on from there to sketch a vision of the type of software that can be created in this area. As befits a speech, there's a little hyperbole in what he says but also an essential truth: process isn't the sexiest of things - but it's an integral and necessary component of society.

As we translate increasing amounts of processes into software, one hopes that we can learn the lessons of the most satisfying aspects of software. At its best, process should be frictionless and unobtrusive like most infrastructure. Why spend an afternoon at the registry of motor vehicles going from queue to queue, filling one form after the other when much of that you can be automated in software? What I fear is lost as we create this software are things like institutional memory and the people-component (the man who explains what that checkbox really means, being able to scribble in the margins of a form, what happens when the next person in a "workflow" is out of the office, or his mail quota has been exceeded etc). There's lots of room for innovation and improvement here.

The terms that have been used about software that aids collaboration have all been unsatisfactory. They have been mostly opaque terms (groupware, knowledge management etc) overloaded and hyped by marketing teams. Correspondingly also, lots of software in this area has been unsatisfactory even if very useful for some groups whether it's mailing lists, usenet. The flight to a quality term like "social software" that people like Clay Shirky have spurred in recent years is an exercise to escape the stigma of the reigning software. I heartily endorse that effort but when I pass the hungry salesmen in the corridor that are trying to sell software for my company, I know that that effort will be in vain. If it's between their year-end bonuses and calling something "social software", you know what's going to win. Thus I predict that our vocabulary for software that supports groups, organizations and communities will continue to be contaminated.

But what about the reality of social software? What collaboration software will be likely to be successful? For me it is clear that one has to start with the platform consideration and from that standpoint we are dealing with the internet and the web and browser clients. Web-native applications, things like wikis for example are going to be part of the picture, not necessarily because they are better but because being based on the most dominant and scaleable platform that we have is virtue enough. More generally, it is going to be applications that take into account the architecture of the web and the internet that will succeed. These will be applications that understand the proposition of identifying resources, the virtue of URIs etc. Those who ignore the lessons of Roy Fielding do so at their peril.

Software that is targeting people will live and die by usability. Those who design software that underlies processes tend to think that they are immune from this but I believe that the same basic principles of interaction design will ultimately apply. No one particularly likes the bureaucracy of process but there's a trait of subversion and resistance in human beings that will undermine any poor tools foisted on them. Paying attention to this will be an important part of success.

On Things

I'll be delphic and try to weasel out of defining what those elusive "things" are. For me, they are a convenient proxy for everything that doesn't fit within the people and process views of things. For businesses, it's relatively mundane things like "documents" that need to be "managed" or keeping track of assets or items we manufacture. Another way to think about 'things' is to consider that people are creative and exist in a culture; software can be applied to the creative process and to establish a sense of place and shared context in society. Some term it "content", more generally it's entertainment, it's the music, the movies, the books that people are interested in and want to participate in and discuss. There's also that whole segment of the software industry, games, that is highly profitable and which seems to be driving things of late - the virtue of idlenesss I suppose.

I'll end by reiterating: people need to communicate so get out of their way and let them collaborate and exchange. Groups, communities and organizations often embody processes, and when using software in support of them, aim for unobtrusiveness and, most crucially, leverage this great network architecture that we have. As for the rest, well that will sort itself out, Darwin and Adam Smith have a lot to say here.

File under: technology, software, design, architecture, social software, people, processes, process, groups, sociology, collaboration, lotus, IBM, social, toli