This paper presents generative patterns that can be used to build an organization and to guide its development process in the domain of software development. By "organization", I mean not so much an institutional organization as one of the communities of mutual interest that form naturally in any culture. These are sometimes called instructive organizations. An organization is usually responsible for some deliverable. The endeavor of building that product within that organization is called a project. The patterns of activity within an organization (and hence within its project) are called a process. Organization, project, and process can be viewed as partial facets of each other. We might find hierarchies or networks of organizations; if so, the patterns here apply in particular to the innermost ones, and in lesser degrees to the more encompassing organization structure (see Divide and Conquer).
I am not so much interested in small (read "simple") projects as in ambitious, complex commercial endeavors that may comprise hundreds of thousands or millions of lines of code. Such projects are common in telecommunications development, and their processes and organizations are a challenge to design. These organizations range in size from a handful of people to a few dozen people. Larger organizations (of hundreds or thousands of people) are beyond the scope of most of the patterns in this language. If such large organizations can be broken into smaller, de-coupled organizations, the patterns apply to each of the parts.
This pattern language probably applies more to young and emerging organizations than to legacy organizations. Legacy organizations, particularly in the sectors of public service and utilities, are almost always destined to be bureaucracies. Young organizations proceed through several stable stages of growth, starting with a visionary and a tightly-knit group. Roles emerge and become more refined as these organizations grow. The organization may grow to the point where it exhibits an internal structure of sub-organizations, each one of which can be the subject of the patterns here. The organization atrophies as it goes into maintenance mode, taking on a stable structure. The patterns here aim at changing, growing organizations, which don't often lend themselves to traditional corporate structures.
All development organizations serve a purpose. This paper does not explore patterns for chartering a development organization, but presumes that an organization is formed within the industry, or within a company, to meet a business need economically. Questions of business practicality are beyond what can be dealt with in depth here. One might look at ``Web of Shopping'' [Alexander 19], ``Household Mix'' [Alexander 35] in Alexander as analogies to how such groups should be formed. Even grosser patterns such as ``Site Repair'' [Alexander 104] provide analogies for finding corporate contexts suitable to highproductivity organizations.
There are "common sense" considerations that don't appear in the contexts or solutions of these patterns. Cultural taboos and standards will leave many of these patterns outside the reach of some organizations. For example, Domain Expertise in Roles presumes that experts are available in the job market. If the domain is breaking brand new ground, experts may not yet be available. Even in familiar territory, experts are scarce, and the culture may not allow the extravagant measures necessary to procure them. As another example, the pattern language makes every attempt to avoid working back project benchmarks from an end date (Size the Schedule). Customers often want to see intermediate benchmarks at agreed intervals, and intermediate benchmarks drive some cultures too deeply for an individual development group to fix. These problems do not invalidate the language, but they may require that some patterns be skipped for a given organization. It is likely that some of these patterns are foundation patterns, and have a larger impact than others if they are skipped: Domain Expertise in Roles, Organization Follows Location, Architect Also Implements, and others are likely foundation patterns.
The success of this pattern language is almost certainly sensitive to contexts that demand future research and exploration. How well-defined is the product at the outset? How much external tool support is available? How short should the edit-compile-go turnaround cycle be? How sensitive is organization to the fault density or fault tolerance of the product system? We also need to study in more depth the degree to which these are, or are not, drivers for successful organizations.