A Generative Development-Process Pattern Language


By: J.O. Coplien
Published in: PLoPD1
Pages: 183-238

Generative patterns to shape a new organization and its development processes.

Category: Organization and Process

Summary: Generative patterns to shape a new organization and its development processes.

Url: http://www.bell-labs.com/people/cope/Patterns/Process/index.html

Pattern: Size the Organization

Pages: 190-192

How big should the organization be? By default, choose ten people. Don't add people late in development.

Category: Organization and Process

Pattern: Self-Selecting Team

Pages: 192-193

There are no perfect criteria for screening team members. Build self-selecting teams, doing limited screening on the basis of track records and broad interests.

Category: Organization and Process

Pattern: Solo Virtuoso

Pages: 193-194

On small projects, do the entire design and implementation with one or two people.

Category: Organization and Process

Pattern: Size the Schedule

Pages: 194-195

Reward developers for meeting schedules. Keep two schedules: an external one (negotiated with the customer) and an internal one (negotiated with the developers). The internal should be shorter than the external by 2-3 weeks for a moderate project.

Category: Organization and Process

Pattern: Form Follows Function

Pages: 195-196

When a project lacks well-defined roles, group closely related activities. Name the resulting abstractions and make them into roles. The activities become the responsibilities of the individuals who will adopt the roles.

Category: Organization and Process

Pattern: Domain Expertise in Roles

Pages: 196-197

To match staff to roles, hire domain experts with proven track records. An individual may play several roles. Multiple players can fill a single role. Domain training is more important than process training. Local gurus are good in all areas.

Category: Organization and Process

Pattern: Phasing It In

Pages: 197

You need to hire long-term staff beyond the initial experts. Phase the hiring program. Start by hiring experts and gradually bring on new people as the project grows.

Category: Organization and Process

Pattern: Apprentice

Pages: 197-198

You can't always hire the experts you need. Each new employee should work as an apprentice to an established expert. The expert must be more than a mentor. Most apprenticeship programs will last six months to a year--the amount of time it takes to make a paradigm shift.

Category: Organization and Process

Pattern: Organization Follows Location

Pages: 198-199

You're assigning tasks and roles across a geographically distributed workforce. The architectural partitioning should reflect the geographic partitioning and vice versa. Assign architectural responsibilities so decisions can be made locally.

Category: Organization and Process

Pattern: Organization Follows Market

Pages: 199-200

There should be a clear role or organizational accountability to individual market segments. In an organization serving several distinct markets, reflect the market structure in the development organization. A core organization can support what is common across all market segments.

Category: Organization and Process

Pattern: Developer Controls Process

Pages: 200-202

What role should be the focal point of project communication? The developer is the process information clearinghouse. Responsibilities of developers include understanding requirements, reviewing the design and algorithms, building the implementation, and unit testing.

Category: Organization and Process

Pattern: Patron

Pages: 202-203

To give a project continuity, provide access to a visible, high-level manager or patron who champions the project, removes project-level barriers, and is responsible for the organization's morale.

Category: Organization and Process

Pattern: Architect Controls Product

Pages: 203-204

A product designed by too many individuals lacks elegance and cohesiveness. An architect should advise, control and communicate closely with developers. The architect should also be close to the customer.

Category: Organization and Process

Pattern: Conway's Law

Pages: 204

The organization is compatible with the product architecture. At this point it is more likely that the architecture can drive the organization.

Category: Organization and Process

Pattern: Architect Also Implements

Pages: 205-206

To preserve architectural vision through to implementation, architects must also implement as well as advise and communicate with developers.

Category: Organization and Process

Pattern: Review the Architecture

Pages: 206

There are always blind spots in the architecture, so architectural decisions should be reviewed by all architects. Architects should review each other's code. Reviews should be frequent, even daily, early in the project. Reviews should be informal, with minimal paperwork.

Category: Organization and Process

Pattern: Code Ownership

Pages: 207-208

Developers can't keep up with a constantly changing base of implementation code, so each code module in the system should be owned by a single developer. Except in unusual, explicit circumstances, code may only be modified by its owner.

Category: Organization and Process

Pattern: Application Design Is Bounded by Test Design

Pages: 208-209

When do you design and implement test plans and scripts? Scenario-driven test design starts when scenario requirements are first agreed to by the customer. Test design evolves along with software design in response to customer scenario changes. When developers decide that architectural interfaces have stabilized, low-level test design and implementation can proceed.

Category: Organization and Process, Testing

Pattern: Engage QA

Pages: 209-210

To guarantee product quality, make QA a central role. Couple it tightly to development when development has something to test. Development's test plan can proceed in parallel with coding, but developers must first declare the system ready for testing.

Category: Organization and Process, Testing

Pattern: Engage Customers

Pages: 210-211

To maintain customer satisfaction, closely couple the customer role to the developer and architect roles, not just to the QA role.

Category: Customer Interaction, Organization and Process

Pattern: Group Validation

Pages: 211-212

To ensure product quality, even before engaging QA, development (with customer input) can validate the design. CRC cards and group debugging help socialize design issues and solve problems. A validation team can work with QA to attack root causes of classes of software faults.

Category: Organization and Process

Pattern: Scenarios Define Problem

Pages: 212-213

Design documents are often ineffective vehicles for communicating the customer's vision of how the system should work. Capture system functional requirements as use cases.

Category: Organization and Process

Pattern: Mercenary Analyst

Pages: 213-214

Supporting a design notation and related project documentation is too tedious for people directly contributing to product artifacts. Use a tech writer who is proficient in the necessary domains but does not have a stake in the design. This person will capture the design using a suitable notation and will format and publish the design for reviews and consumption by the organization.

Category: Organization and Process

Pattern: Fire Walls

Pages: 214-215

Project implementers are often distracted by outsiders who offer input and criticism. A manager should shield developers from interaction with external actors and "keep the pests away."

Category: Organization and Process

Pattern: Gatekeeper

Pages: 215-216

To foster communication with typically introverted engineering personalities, one project member, an extrovert, rises to the role of gatekeeper. This person disseminates leading edge and fringe information from outside the project, "translating" it into terms relevant to the project. The gatekeeper may also leak project information to outsiders, marketing and the corporate control center.

Category: Organization and Process

Pattern: Shaping Circulation Realms

Pages: 216-217

When interaction in an organization is not as it should be, as prescribed by other patterns, give people titles that create a hierarchy with a structure that reflects the desired taxonomy. Give people job responsibilities that suggest the appropriate interactions between roles. Physically co-locate people who should have close communication. People will usually try to respect your wishes if you are reasonable.

Category: Organization and Process

Pattern: Move Responsibilities

Pages: 217-218

Unscrutinized relationships between roles can lead to undesirable coupling at the organizational level. Move responsibilities from the role with undesirable coupling to roles coupled to it from other processes. Responsibilities should not be shifted arbitrarily.

Category: Organization and Process

Pattern: Buffalo Mountain

Pages: 218-220

You want to optimize communications in a large software development organization. For any significant project interaction, the sum of the distances of two collaborating roles from the "center" of the organization should be less than the shortest distance spanning the entire organization. Avoid coupling with neighbors if you're in the outlying 50% of the organization. The intensity of any collaboration should be inversely proportional to the sum of the interacting roles' distance from the center.

Category: Organization and Process

Pattern: Work Flows Inward

Pages: 221-222

Work that adds value directly to the product should be done by authoritarian roles. Work should be generated by customers, filtered through supporting roles, and carried out by implementers at the center. Managers should not be at the center of the communication grid; they will become overloaded and make poor decisions.

Category: Organization and Process

Pattern: Three to Seven Helpers per Role

Pages: 222-224

If there is uneven communication distribution, ensure that each role has three to seven helpers.

Category: Organization and Process

Pattern: Named Stable Bases

Pages: 224-225

How frequently do you integrate? Stabilize system interfaces no more than once a week. Other software can be changed and integrated more frequently.

Category: Configuration Management, Organization and Process

Pattern: Divide and Conquer

Pages: 225

Organizations grow to the point where they cannot easily manage themselves and the decision process breaks down. Identify clusters of roles that have strong mutual coupling but are loosely coupled to the rest of the organization. Form a separate organization and process around those clusters.

Category: Organization and Process

Pattern: Decouple Stages

Pages: 225-226

To decouple stages (e.g., architecture and design) in a development process, for known and mature domains, serialize the steps. Handoffs between steps should take place via well-defined interfaces.

Category: Organization and Process

Pattern: Hub, Spoke, and Rim

Pages: 226

To decouple stages (e.g., architecture, design, coding) in a serialized development process while maintaining responsiveness, link each role to a central role that orchestrates process activities. Parallelism can be reintroduced if the central role can pipeline activities.

Category: Organization and Process

Pattern: Aesthetic Pattern

Pages: 227-228

When an organization has an irregular structure, ensure the organization has identifiable subdomains that can grow into departments of their own as the project grows.

Category: Organization and Process

Pattern: Coupling Decreases Latency

Pages: 229-230

When the process is not responsive enough, development intervals are too long and market windows are not met. Open communication paths between roles to increase the overall coupling-to-role ratio, particularly for communication with central roles.

Category: Organization and Process

Pattern: Prototype

Pages: 230-231

Requirements acquired early in the process are hard to validate without testing. Build a prototype to understand requirements and supplement use cases.

Category: Organization and Process

Pattern: Take No Small Slips

Pages: 231-232

Every week, measure the critical path of the schedule. If it's three days beyond schedule, track a delusion index of three days. When the delusion index becomes ridiculous, then slip the schedule.

Category: Organization and Process

Pattern: Developing in Pairs

Pages: 232

Pair up compatible designers. They can produce more together than they can by working individually. A pair of people is less likely to be blindsided than a single individual.

Category: Organization and Process

Pattern: Interrupts Unjam Blocking

Pages: 232

Events and tasks are too complex to schedule development activities in a linear sequence. When you're about to block on a critical resource, interrupt the provider of the resource to keep you unblocked. If the overhead is small enough, it doesn't affect throughput. It will always improve latency.

Category: Organization and Process

Pattern: Don't Interrupt an Interrupt

Pages: 233-234

You're doing work triggered by Interrupts Unjam Blocking and it's causing thrashing. Turn away further interrupts until the current work is complete.

Category: Organization and Process

Pattern: Compensate Success

Pages: 234-236

To provide appropriate motivation for success, establish lavish rewards for individuals contributing to successful make-or-break projects. The entire team should receive comparable rewards.

Category: Organization and Process