Why Systems Fail and Problems Sprout Anew, a review of the book Systemantics, including John Gall's Basic Systems Axioms. (I'd like to read the book, especially if it has anything to say about human and automatic processes, and how to replace systems.)
See also: Ray Ozzie's essay Why?, from the creator of massively popular collaborative software on why such software is desirable. Along the way he hits social dynamics and how to construct incentives to encourage participation in the collaborative space (and the software is all about replacing, or augmenting, ad-hoc processes with automatic ones. Extrememly hard). I like what he calls the OHIO principal: "if information must be entered in two places, it won't be" [Only Handle Information Once].
It occurs to me that the shift from one-to-one data entry/retrieval (traditional software) to collaborative software is bigger than it might first appear. The fact that the information has to be shared, sorted and merged means that the information entered has to be regarded as a form of input, that is, something that changes the behaviour of the computer, instructions. Usually only the mouse and keyboard are used for input, and the documents don't constitute behaviour-changing instructions on their own -- but collaborative software changes this and suddenly the computer becomes a high bandwidth input/output device, rather than just a recording machine. That shift from low to high bandwidth input makes the software hard to build, even without the social dynamic.
Why Systems Fail and Problems Sprout Anew, a review of the book Systemantics, including John Gall's Basic Systems Axioms. (I'd like to read the book, especially if it has anything to say about human and automatic processes, and how to replace systems.)
See also: Ray Ozzie's essay Why?, from the creator of massively popular collaborative software on why such software is desirable. Along the way he hits social dynamics and how to construct incentives to encourage participation in the collaborative space (and the software is all about replacing, or augmenting, ad-hoc processes with automatic ones. Extrememly hard). I like what he calls the OHIO principal: "if information must be entered in two places, it won't be" [Only Handle Information Once].
It occurs to me that the shift from one-to-one data entry/retrieval (traditional software) to collaborative software is bigger than it might first appear. The fact that the information has to be shared, sorted and merged means that the information entered has to be regarded as a form of input, that is, something that changes the behaviour of the computer, instructions. Usually only the mouse and keyboard are used for input, and the documents don't constitute behaviour-changing instructions on their own -- but collaborative software changes this and suddenly the computer becomes a high bandwidth input/output device, rather than just a recording machine. That shift from low to high bandwidth input makes the software hard to build, even without the social dynamic.