Deploy People Along the Grain of the Domain |
DRAFT |
Department of Computer Science
[email protected] (217) 328-3523 10 December 1993
University of Illinois at Urbana-Champaign
1304 W. Springfield
Urbana, IL 61801 USA
|
Contents |
|
Abstract |
Deploy people 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.
|
Introduction |
This pattern proposes that programmers be deployed so as to have full, individual responsibility for the analysis, design, and implementation of their own parts of the system. In the past, these roles have been split among different people.
|
DEPLOY PEOPLE ALONG THE GRAIN OF THE DOMAIN |
| alias |
| ONE PERSON/MANY HATS |
v v v
|
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.
|
Therefore, deploy people 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. |
Frequently, there will be significant degree of self-selection at work when this patterns is employed. Managers should keep a watchful eye open for the emergence of new roles, as people elect to spontaneously fill them.
v v v
There is a strong echo of Coplien's CODE OWNERSHIP pattern in this pattern. It should be contrasted with the approach suggested by eXtreme Programming advocates, though the effective divisions of labor may not be as different as a simple-minded comparision might suggest.
|
Acknowledgments |
This pattern was drawn largely intact from a discussion of Reuse Teams that took place in early December of 1993 in either comp.object or on an early incarnation of the patterns mailing list. I saved it in my notes, but hadn't found a place to use it until now.
Other than this airing in 1993, this pattern has yet to be reviewed or workshopped. Naturally, any and all comments are welcome. I've found myself using the phrase a lot over the last four years, and need to explain it better on "paper".
|
References |
[Alexander 1979] Christopher Alexander The Timeless Way of Building Oxford University Press, Oxford, UK, 1979 http://www.oup-usa.org/ [Alexander et. al 1977] C. Alexander, S. Ishikawa, and M. Silverstein A Pattern Language Oxford University Press, Oxford, UK, 1977 http://www.oup-usa.org/ [Brooks 1995] Frederick P. Brooks, Jr. The Mythical Man-Month (Anniversary Edition) Addison-Wesley, Boston, MA, 1995 [Coplien 1995] James O. Coplien A Generative Development-Process Pattern Language First Conference on Pattern Languages of Programs (PLoP '94) Monticello, Illinois, August 1994 Pattern Languages of Program Design edited by James O. Coplien and Douglas C. Schmidt Addison-Wesley, 1995 [Foote 1988] Brian Foote Designing to Facilitate Change with Object-Oriented Frameworks Masters Thesis, 1988 University of Illinois at Urbana-Champaign [Foote 1993a] Brian Foote A Fractal Model of the Lifecyle of Reusable Objects (abstract) OOPSLA '93 Workshop on Process Standards and Iteration Washington, DC Jim Coplein, Russel Winder, and Susan Hutz, organizers [Foote & Opdyke 1995] Brian Foote and William F. Opdyke Lifecycle and Refactoring Patterns that Support Evolution and Reuse First Conference on Patterns Languages of Programs (PLoP '94) Monticello, Illinois, August 1994 Pattern Languages of Program Design edited by James O. Coplien and Douglas C. Schmidt Addison-Wesley, 1995This volume is part of the Addison-Wesley Software Patterns Series. [Foote & Yoder 1996] Brian Foote and Joseph W. Yoder Evolution, Architecture, and Metamorphosis Second Conference on Patterns Languages of Programs (PLoP '95) Monticello, Illinois, September 1995 Pattern Languages of Program Design 2 edited by John M. Vlissides, James O. Coplien, and Norman L. Kerth Addison-Wesley, 1996
This volume is part of the Addison-Wesley Software Patterns Series. [Gabriel 1996] Richard P. Gabriel Patterns of Software: Tales from the Software Community Oxford University Press, Oxford, UK, 1996 http://www.oup-usa.org/ [Gamma et al. 1995] Eric Gamma, Richard Helm, Ralph Johnson, and John Vlissides Design Patterns: Elements of Reusable Object-Oriented Software Addison-Wesley Longman, Reading, MA, 1995 [Johnson & Foote 1988] Ralph E. Johnson and Brian Foote Designing Reusable Classes Journal of Object-Oriented Programming Volume 1, Number 2, June/July 1988 pages 22-35 [Roberts & Johnson 1996] Don Roberts and Ralph E. Johnson Evolve Frameworks into Domain-Specific Languages Third Conference on Pattern Languages of Programs (PLoP '96) Monticello, Illinois, September 1996 Pattern Languages of Program Design 3 edited by Robert Martin, Dirk Riehle, and Frank Buschmann Addison-Wesley, 1997