Section 22.1. The Empirical Problem Set: What Are We Aiming At?
22.1. The Empirical Problem Set: What Are We Aiming At?Consider this proposition: some significant subset of social problems that communities confront are (or can be) structured as knowledge creation and/or problem-solving domains similar to the "problems" that the open source software community has found innovative ways to "solve." It would follow that the tools and governance principles of the open source software community, in some modified form, could yield new approaches to community organization and problem solving that build on but go beyond what is currently known about traditional institutions of formal government as well as the more informal notions of "civil society" and "communities of practice." I think the proposition is defensible at least for a class of complex social problems that have three characteristics. The problems we are thinking about should be multi-dimensional in the sense that they call on several different realms of expertise. They should be large in scope, in the sense that they require some kind of division of labor to make progress. And they should be complex in their essence, not just in their implementation. I mean here problems that are substantively and inherently difficult to solve, not difficult only because of the failure of well-understood social or political processes to yield optimal outcomes. An example: if you want to build a new 100-story office building in Manhattan, you will need to pull together many different realms of expertise and organize a rather sophisticated division of labor. Some of the problems you confront will be idiosyncratic social and political issuesthe metalworkers will strike because they know you really need them today, the neighbors will complain about the noise, and deliveries of certain materials will get "held up unexpectedly" somewhere until you pay a friendly fee to the person who can "fix" that problem. But even if you had the magic solution to all these issues, it would still be hard to create this building simply because it is a difficult engineering task to put together a mountain of steel, concrete, and glass that will hang together and stand up to wind, rain, gravity, and use over all the years that it will be there. It would still cost more and take longer than expected. The analogy to software development should be obvious. Complex software is hard to build because it is multidimensional, because it demands a division of labor, and because the problems it is trying to solve are inherently hard. One of the earliest and still best analyses of complex software development projects is Frederick Brooks' The Mythical Man-Month.[1] Brooks' Law states one of the fundamental conclusions from Brooks' assessment: "Programming work performed increases with direct proportion to the number of programmers (N), but the complexity of a project increases by the square of the number of programmers (N2)." Brooks' Law, even if it is not precisely verifiable, is a powerful statement about the software engineering manifestation of a repeated observation on this point. It is hard to build complex systems in considerable measure because it is so hard for people to explain to each other what they are trying to do. Brooks' argument boils down to this simple but profound claim: human communication about complex, often tacit goals and objectives is imperfect. And it gets more imperfect, and at an increasing rate, as it travels between larger numbers of people. So, how do we ever get a functioning division of labor at a large scale to do things like build a New York skyscraper, or write a program with a million lines of code?
One way to manage this dilemma is to enclose the production process within a formal organizationfor example, a proprietary software company. The ideal-type principles of organization here are command and control authority, hierarchical structure for decision making, and tight governance of principal-agent problems. Sustaining that kind of organization depends on maintaining control over the essential resources in the production process. In the software world, that means keeping source code secret. The open source community, by releasing source code, undermines the possibility of setting up the production system in the same way and energizes a quite different organizational model. No one should bet on anything like a wholesale transfer of the organizational model(s) from the open source community to the nonsoftware world; that is too simplistic. What I think we should focus on instead is the means by which the open source community processes, collates, upgrades, corrects, distributes, and implements problem-solving information. In other words, think of open source as a particular kind of information processing algorithm. (It then makes sense to treat the related issues of intellectual property rights and organizational structures that are typically seen as core to the open source community as instrumental, not foundational.) What is foundational to transfer is the information processing "system" that is enacted in this community, and how the results of that process are incorporated into real solutions to practical problems. It may seem quixotic to think about complex social problem solving in political communities as an information processing challenge. After all, we know that innovation in this setting traditionally is slow, constrained, inefficient, and frustrating. And we know, from the work of Max Weber and Joseph Schumpeter and extending into modern public choice theory in political science and management theory in business, some of the reasons why that is the case, in particular the organizational disincentives and cultural impediments to change that are inherent parts of bureaucratic culture and institutions.[2]
Clearly there are a lot of things going on in political communities besides poor information processing. But any experiment, even a thought experiment, has to start somewhere. The proposition here is that information processing is a significant impediment to problem solving in some important political situationsand that, if we can define a set of problem domains that fit this description, we can do something interesting by attacking the nature of the information processing problem first and then thinking about the organizational structure and political problem secondary to that. In other words, design the governance institutions in ways that facilitate information paths that we think will work, rather than the other way around. This is worth experimenting with in part precisely because it is the reverse of many conventional ways of thinking; and in part because we know more about the trade-offs associated with governance institutions than we do about the information processing issues. In sum: think of the target as a set of problem-solving practices which necessarily include an information processing algorithm and the associated institutional structures and incentives that make that algorithm function in real-world settings. These practices will tap into distributed knowledge that in some cases may be present in geographically dispersed individuals or communities; in some cases may be present in separate pieces that have not been integrated into a single, useful whole; and in some cases may be implicit in relatively undefined or tacit practices that "belong" to individuals' experiencesbut are for that very reason not available for use, testing, and refinement by larger groups. Primary care medicine is a good example. My doctor in Berkeley is often solving the same problems of diagnosis and treatment that a primary care doctor in Manhattan solved yesterday, but she has to re-create complex, tacit, and multifaceted knowledge that already exists elsewhere, because there is no structure within which that knowledge can be effectively shared. The bet you need to make to stay with me in this chapter is simply that an important subset of social and political problems fits in this category and might be attacked in this way. |
EAN: 2147483647
Pages: 217