Patterns: An Antidote for "Best" Practices Gone Bad
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Many companies respond to the pressure to improve by adopting "best" practices. The underlying assumption of these efforts is that if others can achieve great success from a practice, then that success can be replicated.
Unfortunately, this is not always true. A practice with a proven record in one situation may do more harm than good in another. Key drivers in the adopting organization may not be addressed by the practices, or the organization may lack the important complementary skills and processes necessary to make the practice successful.
However, incorporating innovative approaches remains critical to an organization's survival. How can this be done without encountering the pitfalls of one-size-fits-all best practice efforts? Patterns provide an alternative approach to incorporating practices in appropriate situations successfully.
Patterns are known to software professionals as a way of describing design. Christopher Alexander, who originated the notion of patterns in building (brick and mortar) architecture, described patterns as a recurring solution to a common problem in a given context and system of forces. Jim Coplien extended the idea to address organizational issues, and his work provides the foundation for using patterns as an alternative to the best-practices approach.
The "Rotation" pattern below illustrates several features that make patterns useful as a means of communicating practices. First, patterns contain a context in which situations to which the pattern is suited are described—in this case, large organizations with some notion of component ownership. Small organizations, or groups using techniques such as Extreme Programming that do not have a component ownership model, might not be good matches for this pattern. Although organizations may consider adopting such practices for a different context, the pattern format at least makes the risk apparent.
Second, patterns clearly identify the specific problems they address, and their solutions. In the example, the focus is on reducing engineer turnover and minimizing its impact. Organizations that recognize their vulnerability to loss of key personnel would be more responsive to the introduction of this practice. The pattern explains the problem (forces) in enough detail for a potential adopter to assess whether the pattern is a good match for the needs and capabilities of the organization.
Finally, the pattern templates identify critical information for introducing the practice. Advocates of a practice can communicate how the practice has worked in similar contexts, identify potentially negative consequences, and provide a rationale for its adoption. As such, the template itself can make managers aware of information gaps that need filling before committing to a new practice.
In summary, patterns can be used to describe valuable practices, not just software designs. They help avoid the pitfalls that can be encountered with best-practice efforts. They allow organizations to select practices that fit best and increase the chances of their successful deployment.
ROTATION
PROBLEM STATEMENT: How do you keep tacit "lore" accessible as specialized product and project teams are formed?
CONTEXT: To support a large software product or architecture, there's a large group of developers organized into geographically distributed goal-, project-, or product-oriented teams. Channels for communication across teams are in place, yet many questions don't readily fit the structure, and engineers often need answers or modifications more quickly than these channels allow. These channels include some notion of component ownership.
FORCES: Tacit information must be disseminated quickly to support the software. When a software group expands from one group to many, the formal, intergroup channels of communication often prove ineffective. Detailed knowledge about components is hard to retain and disseminate. The component owner may feel roped-in by becoming the "expert" for a component. The likelihood of losing or overpaying dissatisfied engineers increases. When the knowledge expert leaves, it is very expensive to reacquire that knowledge. Although some engineers may feel roped-in because of their specialized component knowledge, others resist change. Some component owners may hoard their knowledge to the detriment of the organization.
SOLUTION: Periodically rotate component ownership through apprenticeship. Managers should allow and encourage ex-owners to support new owners. Rotations should be synchronized with release schedules, so former owners will have time to act as mentors. Before rotating engineers, find out whether they are ready to rotate, and where they would like to go next. Rotation should enable engineers to spiral upward; as they rotate, they also move into areas of greater technical challenge and responsibility. As a rule of thumb, rotate engineers about every 12 months, depending on the size and complexity of the components.
RESULT: Developers can more easily learn where to find esoteric knowledge about components. The likelihood that a team member has either owned the component or knows who to ask increases. Staff is more content because they get to work in a variety of areas, reducing turnover. The organization is less vulnerable to the loss of an engineer because previous component owners also have detailed knowledge. Component owners will develop stronger informal networks with other component owners through mentoring and apprenticeship. As engineers rotate, they will increase the portion of the system with which they have hands-on knowledge. By rotating in spirals instead of flat rings, component owners who tend to resist change will have more incentive to move from their existing component to those with more challenge and responsibility. Component owners who are able to learn new components quickly will not feel roped-in by becoming the "expert" in a given area because there would be a clear path of advancement.
CONSEQUENCES: Caution should be used when considering the use of this pattern with large, complex components that require a long time to master; critical knowledge could be lost with disastrous consequences. Engineers might take a short-term view, learning only enough to complete the immediate job and ignore consequences that would take effect after the next rotation. Time and effort are required to train rotating component owners routinely. Some may feel threatened by working in a new area, and may leave or subvert the implementation of the pattern. Growth may be slower because it takes time to train new component owners. Similarly, if the organization is shrinking, this pattern may break down.
RATIONALE: Component owners acquire tacit knowledge as they carry out their responsibilities. Rotation mitigates the risk of losing tacit knowledge in several ways. By periodically placing component owners in the role of mentor, they can share their knowledge with their apprentices. Because many in an organization have experience with any particular component, the organization is less exposed when engineers depart. Finally, by increasing satisfaction, the likelihood of any engineer leaving is reduced.
NOTE
An expanded version of this pattern can be found in Software Architecture: Organizational Principles and Patterns (Addison-Wesley 2001).