A Generative Development-Process Pattern Language A Generative Development-Process Pattern LanguageBy: 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
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
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
Pages: 193-194
On small projects, do the entire design and implementation with one or two people.
Category: Organization and Process
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Pages: 222-224
If there is uneven communication distribution, ensure that each role has three to seven helpers.
Category: Organization and Process
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
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
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
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
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
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
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
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
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
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
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
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