Tuesday, September 16, 2003

Architectures of Consensus and Dissent

Let me be clear. I don't mean to imply that all groupware products necessarily cause groupthink, nor that the role of social software ought to be solely as an aid to dissent. There's a continuum ranging from lockstep agreement and deaf to outside opinion on one side, and multiple diverging opinions within the group on the other. Neither is a positive outcome for a group trying to make a decision or manage a process, and each has many of its own modalities and failure modes. The goal, of course, is to sail between the Scylla of groupthink and the Charibdis of ever-spiraling disagreement. We call that middle path "consensus." There are plenty of mechanisms to reach consensus: talk until everyone agrees; vote and 50%+1 wins; vote and 2/3 wins; one leader decides; etc. Not all work well, not all work always.

The point is that, given that we're beginning to use software as an aid to decision making and group policy-setting, we need to be more cognizant of the implicit effects that the software architecture has on our ability to navigate across this continuum. The Mindworld project is an example of a software architecture -- adjust one pixel at a time -- in which dissent is extremely difficult to put into the mainstream of opinion. USENET is another architecture, in which there is no central artifact to relate to, no time limit, and no built-in mechanism to discourage dissent; thus, it is a perfect example of a software architecture that encourages divergence.

We make these choices all the time when we design software, but I suspect that many of us do it without giving it deep thought, especially because many of the effects of these features on dissent or consensus may be difficult to foresee, or may emerge only through the combination of many features. To return to the MindWorld example, imagine if the interactive primitive wasn't just "set a pixel," but "move a block," where you could paint a rectangle and move it. That change alone would empower dissent significantly; and yes, maybe too much. So now imagine a system in which you can move blocks, but over time, the size of the blocks allowed became smaller and smaller; that's a system that would impose consensus. Is that fair? Perhaps. The role of dissent is most valuable early in the process, when small changes will add to large changes in the end. Or when the system is so misguided later on that a radical realignment is necessary, and perhaps we need a different mechanism to account for that mode of dissent.

One last side note: legal systems and social systems are architectures, too, and architectures of either that repress dissent do themselves a grave disservice.