Archive for March, 2014|Monthly archive page
As Conway states in his retrospective summary:
To save you the trouble of wading through 45 paragraphs to find the thesis, I’ll give an informal version of it to you now: Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure. This turns out to be a principle with much broader utility than in software engineering, where references to it usually occur. I invite you to read the paper, then look around to find applications. My current favorite is the complex of social issues encompassing poverty in America: access to labor markets, housing, education, and health care. After reading the paper, think about how the structures of our various governments affect their approaches to this system.
Does this principle also work inversely? In organising productive communities, especially those working on sourcecode, my working thesis has long been that the architecture of the code informs the architecture of the community. “Monolithic” architectures (which some would just say is another term for, “too big”) tend to processes that more modular ones would find at best hierarchical and probably unacceptable. And we all know how very hard it is to change a system of power, especially one that has operated more or less well enough for years, to something that implicitly limits the power of those who had it before.
Conway’s very famous paper is here.
This blog nicely centralises several threads. It’s anchor lies with U of Manchester (land of the origin of the Industrial Revolution, so long ago), but its reach goes far beyond that.
For me, as a community strategist, I am keenly interested in the kinds of technology that any given productive community adopts. There is no single flavour that suits all tastes; much depends on locality and on the quality and nature of the infrastructure, and this is true regardless of the ultimate (or even initial) internationality of the project.
The article doesn’t really touch on the technological element. Professors use university-provided infrastructure, usually of the bricks and mortar variety (ivy optional); Moocs may use a variety of technologies but not bricks nor mortar. Moocs are probably–one hopes–more than videos or fancy PowerPoint slides. They could include a range of interactive elements. And the particular technology used by a Mooc is likely owned by the institution employing the professor, who has created the course. Moving from one institution to another, in many places an exceptional area of intellectual property identity favouring professorial ownership, thus could be complicated by differences in technology and infrastructure.
The differences that technology make to community identity and possibility, as well as to the degrees of practical freedom, come up all the time in open source environments. Having such a manifold of technologies, as well as, inevitably, licenses and governance protocols, does not produce the best environment for collaborative work and innovation. But it does provide for no end of political machinations and tactical market plays; for business (and politics) as usual.
“Storage of IBM record cards at the Federal records center in Alexandria, Virginia, November 1959. Between 1950 and 1966 the records centers received millions of cubic feet of records, saving the federal government more than the total spent for the entire operation of the National Archives Records Service.” Note: There are about 20 rows of pallets visible, each row is 15 pallets wide, pallets are stacked two high (at least). Each pallet contains 45 boxes of punched cards. Standard card boxes contained 2000 cards. Each card held up to 80 characters, for a total of about 4.3 billion characters of data in this storage facility – about the same as a 4Gb flash drive.