also known as
ONE PERSON/MANY HATS
[Insert additional information about the patterns that this pattern completes here]
Traditional programmer deployment practices deploy the most skill designers at the front-end of the lifecycle. However, the most valuable design insights may not be availabable until much later in the lifecycle, during what traditional models have considered the maintenance phase.
Valuable architectural insight tends to emerge late in the lifecycle, as a result of having addressed requirements from concrete, successive problems drawn from a given domain. It is then that a system can be refactored to consolidate design insight and polish reusable artifacts. (More can be said about this, but that's another tale.)
Such insight can best be harvested if people are deployed along the grain of the domain, and a given individual has responsibility for a well-defined part of it. Organizational categories like Analyst, Designer, Coder, Maintainer, and Reuse Expert can cut across the grain, and greatly increase organizational communication overhead and inertia. However, when responsibility for all these functions for a given part of the system is vested in a single person, the communication overhead for redesign with that part of the system can be largely intracranial. This is a one person/many hats strategy. A single individual can cope far more quickly with on-going bi-directional tensions between top-down elegance and bottom up detail than can a functionally partitioned organization. Such a person can develop a more comprehensive sense of the possibilities that the design space allows, and exploit these to develop more genuinely durable artifacts.
A reusable API or object-oriented framework is, in many respects, a domain-specific language. Given this, Wirth's classic admonition that language design is better done by a single guiding intelligence, rather than by a committee, applies.
Small teams deployed along the grain should be able to glean similar benefits. Team members would be responsible for distinct parts of their team's domain. Metafunctions like pure management and documentation might be factored and assigned to additional individuals. Interpersonal communication would primarily be concerned with interface negotiation, and not become mired with approving changes to internals.
The key here is committing talented designers to a part of the system, and keeping them there until late in the lifecycle, when hindsight from addressing a range of design issues is available.
There is some commonality between this and Alexander's Architect/Builder notions as well. This sort of personnel deployment strategy is a defacto favorite in academic environments, and some small organizations, both of which often exhibit marked productivity advantages over traditional industrial organizations. If an organization really wants to get truly reusable software, it will have to be willing to budget time and talent in such a way as to exploit the insights that lead to it at the point in the lifecycle where they become available. But reuse isn't something that can itself easily be factored into its own department. The people who build and maintain something in the first place have the best, most intimate knowledge of how to generalize it.
I've left myself a certain amount of Alexandrian wiggle room with regard to the question of how one knows where the grain is, especially at the onset of a project. Often its something people settle into.
Deploy programs along the grain of the domain. That is to say, give them dedicated, long term responsibility for a managable piece of the system, thereby enabling them to exploit opportunities to consolidate and improve the reusability of their parts of the system as experience accrues.
[This is where the EXAMPLE goes in an Alexander-style pattern...]
[Describe the patterns that complete this pattern here]