Summary Patlets

A patlet is a short summary of the problem and solution for a pattern. Patlets are often used as an aid to discovering patterns to solve a particular problem at hand. Here, we use the patlets as a way for you to find patterns you are looking for.

10.1 Project Management Patlets

These patlets point to patterns for initial organizational design. You can find the patterns in the section PROJECT MANAGEMENT PATTERN LANGUAGE (4.1).

COMMUNITY OF TRUST (4.1.1):

If you are building any human organization, Then: you must have a foundation of trust and respect for effective communication at levels deep enough to sustain growth.

SIZE THE SCHEDULE (4.1.2):

If the schedule is too long, developers become complacent; but if it is too short, they become overtaxed. Therefore: reward meeting the schedule, and keep two sets of books.

GET ON WITH IT (4.1.3):

If you are starting a project and have enough information to get started on parts of it, Then: don’t wait until you have a complete schedule before starting to do parts of the project

NAMED STABLE BASES (4.1.4):Project Management Patlets 503

If you want to balance stability with progress, Then: have a hierarchy of named stable bases that people can work against.

INCREMENTAL INTEGRATION (4.1.5):

If you want developers to be able to test changes before publishing them, Then: allow developers to build the entire product code independently to allow testing with the very latest base (not the latest Named Stable Base).

PRIVATE WORLD (4.1.6):

If you want to isolate developers from the effects of changes, Then: allow developers to have private work spaces containing the entire build environment.

BUILD PROTOTYPES (4.1.7):

If early acquired requirements are difficult to validate without testing, Then: build a prototype, whose purpose is to understand requirements.

TAKE NO SMALL SLIPS (4.1.9):

If you are getting behind schedule and need additional time resources, Then: take one large planned slip instead of allowing yourself to nickel and dime yourself to death with small, unanticipated

slips.

COMPLETION HEADROOM (4.1.10):

If work is progressing against a set of hard dates, Then: make sure there is COMPLETION HEADROOM (4.1.10) between the completion dates of the largest task and the hard delivery dates.

WORK SPLIT (4.1.11):

If people too close to the problem are escalating their problems, either as a “pork barrel” issue or as something well-intentioned, Then: split work into an urgent and deferred component, with less than half of development work in the urgent half.

RECOMMITMENT MEETING (4.1.12):

If: the schedule can’t be met with simple adjustments to the work queue and staffing, Then: assemble developers and interested managers to recommit to a new strategy based on doing the minimal amount of work to reach a satisfactory conclusion

WORK QUEUE (4.1.13):

If deliverables are ill-defined, you need to allow time to do everything. Therefore: produce a schedule with less output than you have input. Use the list of IMPLIED REQUIREMENTS (4.1.16) (really just names) as a starting point and order them into a likely implementation order favoring the more urgent or higher priority items.

INFORMAL LABOR PLAN (4.1.14):

If developers need to do the most important thing now, Then: let developers negotiate among themselves or “just figure out the right thing to do” as regards short term plans, instead of master planning.

DEVELOPMENT EPISODE (4.1.15):

If we overemphasize individual contributor skills, work suffers. Therefore: approach all development as a group activity as if no one had anything else to do.

IMPLIED REQUIREMENTS (4.1.16):

If you need a way to nail down the functionality that needs to be covered, Then: make a list of functional areas and domains instead of breaking it down into traditional requirements.

DEVELOPER CONTROLS PROCESS (4.1.17):

If you need to orchestrate the activities of a given location or feature, Then: put the Developer role in control of the succession of activities.

WORK FLOWS INWARD (4.1.18):

If you want information to flow to the producing roles in an organization, Then: put the developer at the center and see that information flows toward the center, not from the center.

PROGRAMMING EPISODE (4.1.19):

If you need to split up work across time, Then: do the work in discrete episodes with mind share to commit to concrete deliverables.

SOMEONE ALWAYS MAKES PROGRESS (4.1.20):

If Distractions constantly interrupt your team’s progress, Then: whatever happens, ensure someone keeps moving toward your primary goal.

TEAM PER TASK (4.1.21):

If a big diversion hits your team, Then: let a sub-team handle the diversion, the main team keeps going.

SACRIFICE ONE PERSON (4.1.22):

If a smaller diversion hits your team, Then: assign just one person to it until it gets handled.

DAY CARE (4.1.23):

If your experts are spending all their time mentoring novices, Then: put one expert in charge of all the novices, let the others develop the system.Piecemeal Growth Patlets 505

MERCENARY ANALYST (4.1.24):

If you want to keep documentation from being a critical path road- block for developers, Then: hire a MERCENARY ANALYST.

INTERRUPTS UNJAM BLOCKING (4.1.25):

If you need to schedule urgent development activities according to some reasonable priority scheme, Then: use an interrupt scheme to keep individual problems from blocking the entire project.

DON’T INTERRUPT AN INTERRUPT (4.1.26):

If you’re in the middle of handling an interrupt to keep the project from getting stuck, and a new urgent need arises, Then: continue handling the current issue before moving on to the new one.

10.2 Piecemeal Growth Patlets

These patlets summarize patterns for the growth of an organization once it is up and running. You can find the patterns in the section PIECEMEAL GROWTH PATTERN LANGUAGE (4.2).

SIZE THE ORGANIZATION (4.2.2):

If an organization is too large, communications break down, and if it is too small, it can’t achieve its goals or easily overcome the difficulties of adding more people. Therefore: start projects with a critical mass of about 10 people.

PHASING IT IN (4.2.3):

If you can’t always get the experts you need, Then: grow new experts from new hires.

APPRENTICESHIP (4.2.4):

If you have difficulty retaining expertise, Then: grow expertise internally from existing employees or even new hires.

SOLO VIRTUOSO (4.2.5):

If a project is intellectually small, then overstaffing it is a waste of time and money. Therefore: staff small projects with SOLO VIRTUOSOS.

ENGAGE CUSTOMERS (4.2.6):

If you want to manage an incremental process that accommodates customer input, and if you want the customer to feel loved, Then: engage customers after Quality Assurance and project management are prepared to serve them.

SURROGATE CUSTOMER (4.2.7):

If you need answers from your customer, but no customer is available to answer your questions, Then: create a surrogate customer role in your organization to play advocate for the customer.

SCENARIOS DEFINE PROBLEM (4.2.8):

If you want a good characterization of customer needs, Then: use scenarios to define the problem.

FIRE WALLS (4.2.9):

If you want to keep your developers from being interrupted by extraneous influences and special interest groups, Then: impose a Firewall, such as a manager, who “keeps the pests away.”

GATE KEEPER (4.2.10):

If you need to keep from being inbred, Then: use a GATE KEEPER (4.2.10) role to tie together development with other projects, with research, and the outside world.

SELF SELECTING TEAM (4.2.11):

If you appoint people to a team, it doesn’t come together as a team. But people with outside interests and who wish to joint a team make the best team members. Therefore: teams should be largely self-selecting with limited screening on the basis of track record and outside interests.

UNITY OF PURPOSE (4.2.12):

If a team is beginning to work together, Then: make sure all members agree on the purpose of the team.

TEAM PRIDE (4.2.13):

If a team needs to perform above and beyond the call of duty, Then: instill a well-grounded sense of elitism in its members.

SKUNK WORKS (4.2.14):

If a project innovates too much, then it increases its risk; yet there is a place for innovation. Therefore: give innovation an organizational space and time.

PATRON ROLE (4.2.15):

If you need to insulate Developers so DEVELOPER CONTROLS PROCESS (4.1.17) and provide some organizational inertia at the strategic level, Then: identify a patron to whom the project has access, who can champion the cause of the project.

DIVERSE GROUPS (4.2.16):

If everyone has similar views, you have a good team, but too much normalization leaves important problem areas unaddressed. Therefore: assemble a diverse team, based on different experiences, cultures, and genders.

PUBLIC CHARACTER (4.2.17):

If you need a catalyst to bring people together, Then: recognize some roles as PUBLIC CHARACTERS.

MATRON ROLE (4.2.18):

If your team needs ongoing care and feeding, Then: include a Matron in the team who will naturally take care of social needs of the team.

HOLISTIC DIVERSITY (4.2.19):

If Development of a subsystem needs many skills, but people specialize, Then: create a single team from multiple specialties.

LEGEND ROLE (4.2.20):

If a key person will leave the organization soon, Then: train a key replacement, and have them assume a role named after the key person.

WISE FOOL (4.2.21):

If critical issues do not get aired easily, Then: nurture a Wise Fool to say the things nobody else dares say.Piecemeal Growth Patlets 509

DOMAIN EXPERTISE IN ROLES (4.2.22):

If you need to staff all roles, it’s difficult to determine how to match people to roles to optimize communication. Therefore: match people to roles based on domain expertise, and emphasize that people play those roles in the organization.

SUBSYSTEM BY SKILL (4.2.23):

If you need to organize subsystems for the long haul, Then: divide them up by skills.

MODERATE TRUCK NUMBER (4.2.24):

If you can’t eliminate having a single point of failure in allocating expertise to roles, Then: spread expertise as far as possible, but not more so.

COMPENSATE SUCCESS (4.2.25):

If enterprises are to succeed, they must reward the behaviors that portend for success; but, these behaviors are varied, and success is difficult to measure. Therefore: establish a spectrum of reward mechanisms that reward both teams and individuals.

FAILED PROJECT WAKE (4.2.26):

If people have put their hearts and souls into a project, only to have it canceled, Then: celebrate its demise; hold a “wake” for it.

DEVELOPING IN PAIRS (4.2.28):

If you want to improve the effectiveness of individual developers, Then: have people develop in pairs.

ENGAGE QUALITY ASSURANCE (4.2.29):

If developers can’t be counted on to test beyond what they already anticipate what might go wrong, Then: engage Quality Assurance as an important function.

APPLICATION DESIGN IS BOUNDED BY TEST DESIGN (4.2.30):

If you want to organize the interworking between test developers and software developers, Then: organize the process so APPLICATION DESIGN IS BOUNDED BY TEST DESIGN.

GROUP VALIDATION (4.2.32):

If you want to avoid being blindsided in quality assurance, Then: ENGAGE CUSTOMERS (4.2.6) and DEVELOPING IN PAIRS (4.2.28) and others to validate the system.

10.3 Organizational Style Patlets

Good design lends a sense of style to anything we build. Each great organization has its own style. These patterns shape the “style” of an organization. Different organizational styles fit different needs, so these patterns provide a good foundation for tailoring an organization to your business and market. The patterns can be found in the section ORGANIZATIONAL STYLE PATTERN LANGUAGE (5.1).

FEW ROLES (5.1.2):

If your organization has high communication overhead and latency, Then: identify the roles in the organization, and keep the number of roles to sixteen or fewer.

PRODUCER ROLES (5.1.3):

If your organization has too many roles, but does not know which to eliminate, Then: identify roles as Producers, Supporters, or Deadbeats; eliminate the Deadbeats, and combine some of the Supporters.

PRODUCERS IN THE MIDDLE (5.1.4):

If your developers are somewhat lost, Then: make sure the producer roles are at the center of all communication.

STABLE ROLES (5.1.5):

If you have to deal with project disruptions, Then: keep people in their primary roles, and deal with disruptions as temporary tasks.

DIVIDE AND CONQUER (5.1.6):

If an organization is getting too large for communications to be effective any more, Then: try partitioning it along lines of mutual interest and coupling, forming a separate organization and process.

CONWAY’S LAW (5.1.7):

If organization structuring concerns are torn between geography, expertise, politics, and other factors, Then: align the primary organizational structuring with the structure of the business domains, the structure that will be reflected in the product architecture.

ORGANIZATION FOLLOWS LOCATION (5.1.8):

If you need to distribute work geographically, communications suffer, but you can limit the damage if work is partitionable. Therefore: organize work at locations so groups of people that work together are at the same location.

ORGANIZATION FOLLOWS MARKET (5.1.9):

If there is no clear organizational accountability to a market, Then: make some organization accountable for the market to assure that the market’s needs will be met.

FACE TO FACE BEFORE WORKING REMOTELY (5.1.10):

If a project is divided geographically, Then: begin the project with a meeting of everyone in a single place.

FORM FOLLOWS FUNCTION (5.1.11):

If there is little specialization, and people don’t know where to turn for answers to technical questions, Then: Create domains of expertise called roles that cluster around artifacts or specialization.

SHAPING CIRCULATION REALMS (5.1.12):

If you need mechanisms to facilitate the communication structures necessary for good group formation, Then: shape circulation realms.

DISTRIBUTE WORK EVENLY (5.1.13):

If you want to optimize utilization of human resources, Then: alleviate hot spots of overload on specific groups and individuals in your organization by Distributing Work Evenly

RESPONSIBILITIES ENGAGE (5.1.14):

If central roles are overloaded but you don’t want to take them out of the communication loop Then: intensify communication more among non-central roles to lighten the load on the central roles

HALLWAY CHATTER (5.1.15):

If developers tend to huddle around the organizational core or supporting roles are inadequately engaged with each other, Then: rearrange responsibilities in a way that encourages less isolation and more interworking among roles and people.

DECOUPLE STAGES (5.1.16):

If stages are too interleaved for the good of some high-context development where phases can be separated to increase parallelism, Then: serialize process steps, with well-defined hand-offs between steps.

HUB SPOKE AND RIM (5.1.17):

If you want to DECOUPLE STAGES in a high-context development process, Then: orchestrate the process with a hub role, and minimize coupling between other roles, in a hub-spoke-and-rim geometry.

MOVE RESPONSIBILITIES (5.1.18):

If you want to change coupling between roles (particularly if you want to decouple roles), Then: move responsibilities from one role to another.

UPSIDE DOWN MATRIX MANAGEMENT (5.1.19):

If the right skills and resources don’t seem to be applied to a particular aspect of the work, Then: go beyond corporate structures to leverage teams in other organizations (customer, partners, other internal organizations)

THE WATER COOLER (5.1.20):

If you need more communication between institutionalized organizations, Then: leave space for everyday human activities at the workplace that can provide more complete and informal communication THREE TO SEVEN HELPERS PER ROLE (5.1.21):514 Chapter 10 Summary Patlets

If you want to even out communication, Then: at least try to limit

communication to THREE TO SEVEN HELPERS PER ROLE, and to pull up the outliers to the same level of engagement.

COUPLING DECREASES LATENCY (5.1.22):

If you need a high throughput development process, Then: increase coupling between roles to decrease latency.

10.4 People And Code Patlets

People and code are the two most important components of a software development organization. Customers wouldn’t exist without code to sell to them, and code wouldn’t exist without people. People write code, and the structure of code in turn affects how people organize. These patlets point to patterns that help an organization align the people and code structures properly. The patterns themselves can be found in the section PEOPLE AND CODE PATTERN LANGUAGE (5.2).

ARCHITECT CONTROLS PRODUCT (5.2.3):

If a project has a long life, Then: use the architect to carry the vision forward and serve as the long-term keeper of architectural style.

ARCHITECTURE TEAM (5.2.4):

If you are building a system too large or complex to be thoroughly understood by a single individual, Then build a team that has both the responsibility and the power to create the architecture.

LOCK ’EM UP TOGETHER (5.2.5):

If your team is struggling to come up with an architecture, Then: isolate them physically for several days where they can work uninterrupted.

SMOKE FILLED ROOM (5.2.6):

If you need to make a decision quickly and there are reasons to exclude others, Then: make the decision covertly so that the rationale remains private, though the decision will be publicized.

STAND UP MEETING (5.2.7):

If there are pockets of misinformation or people out of the loop: Then: hold short daily meetings to socialize emerging developments.

DEPLOY ALONG THE GRAIN (5.2.8):

If reuse is suffering from fragmentation of responsibilities for an artifact, Then: give people dedicated, long term responsibility for a management piece of the system.

ARCHITECT ALSO IMPLEMENTS (5.2.10):

If an architect is on an ivory tower, they are out of touch; yet someone needs to take the big and long view and reconcile it with practice. Therefore: the architect is materially involved in day-to-day implementation.

GENERICS AND SPECIFICS (5.2.11):

If you have many new people, Then: put the experienced people on generic parts of the work, and give specific assignments to the new people.

STANDARDS LINKING LOCATIONS (5.2.12):

If you have geographically separated development, Then: use standards to link together parts of the architecture that cross geographic boundaries.

CODE OWNERSHIP (5.2.13):

If you need responsibility for code and want to build on DOMAIN EXPERTISE IN ROLES (4.2.22), Then: give various individuals responsibility for the overall quality of the code.

FEATURE ASSIGNMENT (5.2.14):516 Chapter 10 Summary Patlets

If you are trying to partition work in a large project, Then: make assignments of features to people.

VARIATION BEHIND INTERFACE (5.2.15):

If more than one person is developing software, then changes affect not only the code, but people as well. Therefore: create interfaces around predicted points of variation.

PRIVATE VERSIONING (5.2.16):

If you want to enable incremental changes without publishing them, Then: set up a mechanism for developers to version code without checking it in to a public repository.

LOOSE INTERFACES (5.2.17):

If you need to develop systems rapidly in an environment where communication is less than optimal, Then: limit the number of explicit, static, interfaces. Use loose interfaces like callbacks.

SUBCLASS PER TEAM (5.2.18):

If subsystem teams have different Design points, Then: where two subsystems collide in one class, assign them to different layers of the class hierarchy.

HIERARCHY OF FACTORIES (5.2.19):

If you have a creational system which creates different products specified by different groups, Then: set up factories in a hierarchical arrangement, where each knows about 1 level below only.

PARSER BUILDER (5.2.20):

If you need you create objects based on type information in an input stream, Then: use a parser builder which reads type information from the stream and builds the appropriate objects based on this information.

10.5 Patlets From Other Pattern Languages

This book has been a team effort, incorporating pattern material from many sources including works by Alistair Cockburn, Ward Cunningham, Steve Berczuk, and others. Sometimes we have included

other patterns almost intact, and in other cases we have updated or edited the patterns to fit into the format or the context of the pattern languages in this book. For example, many of Alistair Cockburn’s patterns have essentially the same content here as in their original publication, but have been radically reformatted from their original form for the sake of consistency.

Some patterns, while still relevant to the topic of organizational structure, didn’t quite fit in the pattern languages here. That might be because they describe process instead of structure, or because they are idioms sensitive to particular situations, or because they are off-topic, or because they are proto-patterns awaiting broad substantiation. But we still refer to some of those patterns and we commend them to you as great reading.

Here, we provide patlets for those patterns to which we refer, but which didn’t make it into the book. Because these are often quotes from others, they do not follow the patlet style we used in our own patlets. Some of the patlets come verbatim from Linda Rising’s Pattern Almanac [Rising2000]—which is a great source of other organizational pattern reference material.

10.5.1 Arranging The Furniture

Your established team is entering a transition period where members are replaced by newcomers who must quickly come to grips with large and complex software modules. People are territorial and need to mark their intellectual territory to establish a feeling of ownership. Newcomers should move in by cosmetically arranging code. This must be a background, incremental task and should not be used as an excuse to trash the backyard. Verbatim from [Rising2000], p. 27. From [Taylor1999], pp. 632-635. Referenced in CODE OWNERSHIP (5.2.13).

10.5.2 Ad-Hoc Corrections

It’s difficult to keep documents up to date. Keep a master hard copy of the design accessible to the entire team. Anyone who updates the design must make corrections in the margin, delete sections that no longer apply, or write a description of the change. Ultimately, one team member should update on-line copies to reflect the corrections. (Verbatim from [Rising2000], p. 119.) From [Weir1998]. Referenced in MERCENARY ANALYST (4.1.24).518 Chapter 10 Summary Patlets

10.5.3 All At Once

If your downstream implementation teams are ready to get started even though requirements aren’t ready, Then let them go ahead and make progress based on their instinct and information at hand. [Cockburn2003] Referenced in GET ON WITH IT (4.1.3).

10.5.4 Architecture Definition Team

You don’t want the architecture to become convoluted, so create a small team of resonating minds charged with the job of defining the initial architecture. [Meszaros1997] Referenced in ARCHITECTURE TEAM (5.2.4).

10.5.5 Balanced Team

Using teams of similar, like-minded individuals to develop use cases can result in a set of limited, narrowly ranged use cases that do not satisfy everyone’s needs. Therefore: Staff the team with people from different specialties to champion the interests of the stakeholders in the development process. Make sure the team contains both devel-opers and end users. From [Bramble2002], p. 39. Referenced in DIVERSE GROUPS (4.2.16).

10.5.6 Business Process Model

If you need to understand requirements and business needs beyond

the use cases, Then: Understand first the network of agents and commitments that make up the business. Specify the conversations that take place at an appropriate level of abstraction, so that they are stereotypes for actual stories. Get people to tell these stories. Ensure that you produce both ’before’ and ’after’ business process models. Eliminate conversations that do not correspond to business objectives (or discover the missed objective). Ensure every objective is supported by a conversation. The solution is verbatim from [Graham2003], p. 59. Referenced in WORK SPLIT (4.1.11).Patlets From Other Pattern Languages 519

10.5.7 Clear The Fog

You don’t know the issues well enough to put together a sound plan, so deliver something. This will tell you the real issues. (Verbatim from [Rising2000], p. 168.) From [Cockburn1998]. Referenced in BUILD PROTOTYPES (4.1.7) and in the patlet MICROCOSM (10.5.18), below.

10.5.8 Creator-Reviewer

People make mistakes. It’s difficult to see problems and errors in your own work. When one or two designers are producing a design, there is a strong likelihood of undetected errors. Have each designer produce a draft or a complete design. Each of one or more reviewers receives a copy and provides feedback. (Verbatim from [Rising2000], p. 119.) From [Weir1998]. Referenced in GROUP VALIDATION (4.2.32).

10.5.9 Demo Prep

This pattern language is a “preparation for customer demonstrations” ([Rising2000], p. 48). The pattern language comprises seven patterns named ELEMENT IDENTIFICATION, CATALYTIC SCENARIOS, MUTABLE CODE, PROTOTYPING LANGUAGES, LIGHTWEIGHT USER INTERFACES, JUDICIOUS FIREWORKS, and ARCHIVE SCENARIOS. From [Coram1996]. Referenced in BUILD PROTOTYPES (4.1.7) and SCENARIOS DEFINE PROBLEM (4.2.8).

10.5.10 Designers Are Our Friends

How should testers work with designers? Build rapport with designers. Approach designers with the attitude that the system has problems that require cooperation to resolve. Designers and testers have a common goal. Use GET INVOLVED EARLY (10.5.13) and DOCUMENT THE PROBLEM. (Verbatim from [Rising2000], p. 126.) From [Delano1998]. Referenced in ENGAGE QUALITY ASSURANCE (4.2.29) and in the patlet GET INVOLVED EARLY (10.5.13), below.

10.5.11 Early And Regular Delivery

You don’t know what problems you will encounter during development, so deliver something early. Discover what you don’t know you don’t know. Deliver regularly and improve each time. CLEAR THE FOG (10.5.7) is the general expression of this strategy. (Verbatim from [Rising2000], p. 168.) From [Cockburn1998]. Referenced in BUILD PRO-TOTYPES (4.1.7), SIZE THE SCHEDULE (4.1.2), LOOSE INTERFACES (5.2.17), and in the full text of CLEAR THE FOG (10.5.7), which is abstracted above.

10.5.12 Establish The Business Objectives

People tend to over-emphasize Use Cases as the final authority on requirements at the expense of other considerations and particularly of business needs. Therefore: Hold a workshop involving as many stakeholders as possible. Make sure that potential users are represented by marketing personnel or the results of focus groups, surveys, etc. Find a good facilitator. Agree a mission statement. Find measures for each objective. Agree a numerical rank ordering of the priorities. The solution is verbatim from [Graham2003], p. 54. Referenced in WORK SPLIT (4.1.11).

10.5.13 Get Involved Early

You’re a system tester working on a large software project. To maximize support from the design community, establish a working relationship with the designers early in the project, for example, learn the system and the features along with the designers or attend reviews of requirements and design documentation. Invite designers to reviews or test plans. Use DESIGNERS ARE OUR FRIENDS (10.5.10). Don’t wait until you need to interact with a designer; by that time it’s too late. Trust must be built over time. (Verbatim from [Rising2000], p. 126.) From [Delano1998]. Referenced in DESIGNERS ARE OUR FRIENDS (10.5.10), above, and in ENGAGE QUALITY ASSURANCE (4.2.29).

10.5.14 Gradual Stiffening

The requirements and use cases may evolve during the lifetime of the project. How do you respond to such developments? Should you adhere strictly to the original plan? If not, what is fixed and what should be allowed to vary? Therefore: A web site development project should start with loose design but clear business objectives, defined use cases and types and a sound project plan. Allow the site structure to stiffen the design only as the site unfolds and only completely towards the end of the project. The entire patlet is abstracted verbatim from [Graham2003], p. 77. Referenced in WORK SPLIT (4.1.11).

10.5.15 Guru Does All

A newly formed team is given a project with a tight schedule, uncertain requirements, uneven distribution of skills, and new technologies. Let the most skilled and knowledgeable developer drive the design and implement the critical pieces. (Verbatim from [Rising2000], p. 130.) From [Olson1998a], pages 153-154. Referenced in ARCHITECT  ALSO IMPLEMENTS (5.2.10).

10.5.16 Market Walk-through

When PRODUCT INITIATIVE (10.5.22) has been followed, hold a walkthrough of program and product concepts with both the development and business sides of an organization. When this pattern has been followed, use IMPLIED REQUIREMENTS (4.1.16). (Verbatim from [Rising2000], p. 52.) From [Cunningham1996], p. 375. Referenced in IMPLIED REQUIREMENTS (4.1.16) and in PRODUCT INITIATIVE (10.5.22), below.

10.5.17 Master-Journeyman

You need to partition the design work for a large system. There must be a chief architect or small team to provide design integrity. Yet in a large development project, it might be possible for this core team to do all the design work. The core team should provide an overview of the system architecture and divide the system into independent components. Journeymen architects then design the components and act as chief architects for the components. (Verbatim from [Rising2000], p. 118.) From [Weir1998]. Referenced in ARCHITECTURE TEAM (5.2.4).522 Chapter 10 Summary Patlets

10.5.18 Micro Cosm

You have to create a plan but have never done this sort of project, so run an 8- to 12-week instrumented pilot to get productivity and throughput data for your plan. CLEAR THE FOG (10.5.7) is the general expression of this strategy. (Verbatim from [Rising2000], p. 168.) From [Cockburn1998]. Referenced in BUILD PROTOTYPES (4.1.7).

10.5.19 Owner Per Deliverable

Be sure every deliverable has one and only one owner. This is a general strategy with specializations: DAY CARE (4.1.23), FUNCTION OWNER AND COMPONENT OWNER, and TEAM PER TASK (4.1.21). (Adapted from [Rising2000], p. 169.) From ([Cockburn1998], p. 220-221). Widely referenced in many patterns, but key to CODE OWNERSHIP (5.2.13), FUNCTION OWNER AND COMPONENT OWNER, SUBCLASS PER TEAM (5.2.18), and TEAM PER TASK (4.1.21).

10.5.20 Participating Audience

You cannot satisfy stakeholders’ needs without their input and feedback. Therefore: Actively involve your customers and internal stakeholders in the use case development process when possible. From [Bramble2002], p. 35. Referenced in ENGAGE CUSTOMERS (4.2.6).

10.5.21 Peace Maker

A peacemaker is a placeholder in an organization who tries to calm and hold things together until a leader can be found or a reorganization is complete. The peacemaker should be someone who is well liked but who is not necessarily technically proficient. Usually this individual has many years with the company, knows the political ropes, and can buy time for a team as well as the team’s management. Usually PEACE MAKER (10.5.21) follows SACRIFICIAL LAMB and precedes CULT OF PE R S O N A L I T Y or GU R U DO E S AL L (10.5.15). (Verbatim from [Rising2000], p. 131.) From [Olson1998a], p. 168. Referenced in MATRON ROLE (4.2.18). In this book, SACRIFICE ONE PERSON (4.1.22) is an alias for SACRIFICIAL LAMB.Patlets From Other Pattern Languages 523

10.5.22 Product Initiative

When a wish list of features and functions is created for a product, clearly define an initiative for product improvement and be sure everyone understands the initiative. When this pattern has been followed, use MARKET WALK-THROUGH (10.5.16). (Verbatim from [Rising2000], p. 52.) From [Cunningham1996], pp. 374-375. Referenced in IMPLIED REQUIREMENTS (4.1.16) and in MARKET WALK-THROUGH (10.5.16), above.

10.5.23 Proto Types

To avoid the risk of commiting to production decisions prematurely and the problems of long-term maintainability of code, work with customers to initially build LO FIDELITY PROTOTYPES using paper widgets, drawings, paper stickies, and index cards. If the skill and tools are present, build HIGH FIDELITY PROTOTYPES. From ([Whitenack1995], p. 288). Referenced in BUILD PROTOTYPES (4.1.7).

10.5.24 Query Objects

You’re using REPORT OBJECTS and need to create queries for reports at run-time. Create objects that represent queries. Define operations on these objects and a method to return query results. (Verbatim from [Rising2000], p. 41.) From [BrantYoder1999]. Historically from [BrownWhitenack1999]. Referenced by PARSER BUILDER (5.2.20).

10.5.25 Shared Clear Vision

The lack of a clear vision about a system can lead to indecision and contrary opinions among the stakeholders and can quickly paralyze the project. Therefore: Prepare a statement of purpose for the system that clearly describes the objectives of the system and supports the mission of the organization. Freely distribute it to everyone involved in the project. From [Bramble2002], p. 80. Referenced in UNITY OF PURPOSE (4.2.12).524 Chapter 10 Summary Patlets

10.5.26 Shearing Layers

Software systems cannot stand still, but different components change at different rates. Factor the system so that components that change at similar rates are together. (Verbatim from [Rising2000], p. 21.) From [Foote2000]. Referenced by VARIATION BEHIND INTERFACE (5.2.15).

10.5.27 Small Writing Team

Using too many people to write a use case is inefficient, and the compromise made to align the many different points of view may result in a less than satisfactory system. Therefore: Restrict the number of people refining any one work product to just two or three people. From [Bramble2002], p. 31. Referenced in SIZE THE ORGANIZATION (4.2.2).

10.5.28 Skill Mix

When team membership is likely to change, separate subsystems by staff skill requirements. This allows specialists to work in their area of expertise and enables successors to see the results of these special abilities in isolation. (Verbatim from [Rising2000], p. 135.) From [Cockburn1996]. Referenced by CONWAY’S LAW (5.1.7) and DEPLOY ALONG THE GRAIN (5.2.8).

10.5.29 Work Allocation

Work is not always assigned to right place, done at the right time and assigned to correct people. Go beyond the historical, organizational, financial or political barriers and allocate work to produce the most effective outcome. Unpublished; see [Beedle2000]. Referenced in UPSIDE DOWN MATRIX MANAGEMENT (5.1.19).