Chapter 19. PBE Misconceptions

As we come to the end, we reflect on the journey. With new ideas, skills, and approaches, it’s exciting to think of the impact we can have on our projects. However, taking the next steps is never as easy or straightforward as we hope it will be. It’s with a dash of reality and tempered enthusiasm that we reflect. Will everyone on the team automatically pick up PBE? Can we just flip a switch and have a team that shares a culture, skills, and view of the right path forward? Adopting a new approach becomes much more difficult as we scale across multiple teams and the entire organization. There are challenges in navigating the road ahead. To help us forge ahead we can look at misconceptions and roadblocks that may arise. As they say, “Knowledge is power.”

PBE Eliminates Creativity

A good place to start is creativity. How will developers on the team react to PBE? Will people feel constrained and limited? Will adopting PBE stifle the creativity of the team? Will they become bored and unproductive and look elsewhere for better, more interesting opportunities? These fears and concerns are common and arise from PBE concepts such as the use of automation and reuse of solutions created by others.

Let’s take a look at some ways in which we can address and counteract this misconception:

• Pattern specifications and implementations. We choose the balance of pattern specifications and implementations that we use in our projects. Adopting an approach that focuses on pattern specifications could help to alleviate concerns about creativity and automation by using patterns as guidance and blueprints. A trade-off with this approach is that we miss out on the benefits of automation. The best approach is to find a balance between pattern specifications and pattern implementations.

• Reinventing the wheel. PBE does not look to automate all tasks, but to focus on common and recurring tasks—specifically those that have a proven, best-practice solution. Do pattern implementations really reduce the creativity of our teams? How much creativity is there in creating the same solution over and over again? Pattern implementations automate the repetitive and mundane tasks, allowing team members to spend more time on interesting and creative ones.

• Pattern production and application. PBE also encourages us to continuously look for and apply patterns. This is highly creative and challenging, whether we are trying to identify and codify a new pattern or apply an existing pattern (specifications or implementations) to a specific problem.

PBE Patterns and Guidelines such as Antipatterns (Chapter 11), Pattern Opportunity (Chapter 11), and Simple Solution Space (Chapter 10) are some examples of the opportunities provided to exercise creativity.

PBE Introduces Project Risk

Another misconception is that PBE will introduce unnecessary risk into a project. Project leadership needs to manage project risk and a usual suspect is new approaches. They’ll request that the transition to the new approach be done later, on another project.

A good way to start dispelling this misconception is to cite the PBE Core Values. In such a review and discussion, there are some key ideas that should surface:

• Iterative and incremental. PBE is not a one-time effort, nor is it a waterfall approach to solving all the problems associated with a project. In each of our iterations we attempt to figure out how best to leverage patterns. In addition, even with the patterns we create, we apply similar thinking. Within each iteration we evaluate the value and completeness of the patterns, with a focus on adding value to the patterns and the projects that consume those patterns.

• Creativity and best practices. We want to leverage the creativity and best practices of the team. We want to communicate the best practices in a standard format and ideally automate their use.

• Process integration. We seek to integrate PBE into our software development process. We do not throw away the previous investments made in defining and refining our software development process.

• Project recovery. In some cases we may not be able to convince leadership that PBE has a role in our current project. In such cases we need to keep in mind that PBE can also serve an important role in project recovery. Pattern implementations can provide a significant boost to team productivity and the quality of the resulting solution.

PBE Patterns such as Determine Business Impact (Chapter 11), Meet-in-the-Middle Pattern Creation (Chapter 12), Pattern Creation Lifecycle (Chapter 12), and Piecemeal Pattern Creation (Chapter 10) are some examples of patterns that you can use to manage risk.

Pattern Identification Is Not for Everybody

In some cases people will develop a belief that only a few select people can define patterns. They see patterns as being invented by others—the top performers, industry thought leaders, and software vendors.

However, patterns are not invented but discovered. And there are a number of skills and traits that come into play. For instance, observational skills are important, as pattern discovery comes from observing different projects and being able to make a pairing between a recurring problem and a given solution. There are also cultural aspects that come into play; we need to create a culture that looks for and values patterns.

Once we’ve identified the essence of a pattern (the problem/solution pair), there are resources available that we can consult to help us write the pattern. These resources include books and pattern-writing conferences, as well as other Pattern Specification Authors. Pattern-writing conferences are organized as workshops where participants submit their pattern(s), which are then discussed with the goal of improving their descriptions. Pattern Languages of Programs (PLoP) conferences are probably the best-known pattern-writing conferences. Books such as Patterns Hatching¹ by John Vlissides provide tips on how to write patterns. This book also provides an interesting insight into how the GoF patterns were identified, captured, and disseminated. It is interesting to see that quite a few discussions and iterations went into how the GoF patterns were developed. In the end, those of us consuming the patterns just see a finished book with a great set of patterns. Viewing the finished product without an understanding of the effort, iterations, and debate that went into the patterns can make pattern authoring seem intimidating.

We also need to know some of the signs that alert us to potential patterns. As we work on our projects, do we

• Keep solving the same problem?

• Reuse existing solutions via copy and paste?

• Keep answering the same questions?

• Encounter a sense of déjà vu?

If we answer yes to any of these questions, we should consider that we might be dealing with a pattern. We can’t be afraid to get started; all pattern authors start with a first pattern. To help in this effort, we can consider PBE Patterns and Guidelines, including Domain-Driven Patterns (Chapter 10), Pattern Opportunity (Chapter 11), Recurring Solution (Chapter 11), and Use Patterns to Find Patterns (Chapter 16).

Patterns Need to Be Used Everywhere, All the Time

Sometimes people get a little too enthusiastic about using patterns. Every problem needs to have a pattern that is used to solve it. Every solution where a pattern is not yet used needs to become a pattern. All patterns, all the time, everywhere and anywhere.

To address this misconception, we need to be systematic, disciplined, and quantifiable in how we use patterns. We do not use patterns everywhere and for any reason. We do not create patterns out of any and all solutions.

In adopting PBE, we analyze the problems that we have to address. In some cases we will find that the requirements, content, and situation make it ideal for us to apply an existing pattern. In some cases we will find that a pattern does not exist; however, the opportunity to create one for the situation is appealing. In further analyzing the situation, we find that we can achieve a positive ROI on the pattern, using it in multiple situations on the current project and others.

In some cases, however, we will find that patterns do not exist in an area for a reason. Perhaps the situation is so unique that it does not make sense to capture the solution as a pattern. In some cases it may be that we have a solution for the problem, but we would not consider it a best-practice solution. It works, but we wouldn’t want anyone else to reuse it.

As much as we need to be open to creative solutions and on the lookout for patterns, we also need a critical and discerning eye. We do not want to end up creating a junkyard in our pattern repository, whereby we create large numbers of meaningless patterns that make it difficult to find patterns that truly add value. To help address this misconception, consider PBE Patterns and Guidelines, including Determine Business Impact (Chapter 11), Pattern Density (Chapter 16), Pattern Selection Driven by Requirements (Chapter 16), Pattern Testing (Chapter 13), and Select Large-Scope Patterns First (Chapter 16).

PBE Is Overly Formal

Some see PBE as too formal—too many steps, roles, work products, and generally just too many things to do and remember.

The PBE Core Values can be a great way to dispel this misconception. They provide a short, simple, easy-to-remember set of ideas that serve as a foundation to help in succeeding with PBE. Some additional considerations to keep in mind:

• Pattern consumption. We can think of patterns as another tool in our toolbox, to be used when needed. We don’t need to put patterns everywhere or make the solution fit the pattern. We use them when and where they make sense; we need to be practical and pragmatic.

• Pattern production. Being practical and pragmatic carries over to the production side as well. We evaluate which patterns should be created and how much investment we put into the creation effort. Such evaluation can be as formal as needed. The actual creation of the pattern can be done using many of the skills, steps, and roles that we traditionally use in our other projects. Changing focus, we also see that we can make Pattern Users more productive by creating pattern implementations that automate steps and work product generation. Less to remember, less to do.

• Pattern practice and process customization. The PBE Practice should be used along with other practices in creating a development process that suits the needs of the team and development organization. We need to ensure that the process provides the correct level of formality as desired and needed. More details regarding the PBE Practice are provided in Chapter 8, “PBE and the Software Development Process,” and Appendix F.

Some of the PBE Patterns and Guidelines to consider in managing overhead and formality in your development efforts include Determine Business Impact (Chapter 11), Integrated Patterns and DSLs (Chapter 15), Pattern Density (Chapter 16), Pattern Packaging (Chapter 14), and Use an Asset Repository (Chapter 16).

PBE Is Only for Design

In some cases people consider patterns only for design. Figure 19.1² shows the distribution of project effort by development discipline.³ If we look at all of the work that needs to get done in defining, designing, implementing, testing, deploying, and maintaining a software application, it is very clear that only a fraction of the time is spent in design; as shown in the figure, design represents only 15% of the overall project effort.

Figure 19.1. Effort allocated to each of the disciplines within the SDLC

PBE is about patterns, and patterns can exist across the SDLC. PBE applies to the core development activities of software development covering requirements, architecture, design, implementation, assessment, environments, and deployment, which, according to Figure 19.1, represent 80% of a project. Taking a holistic view of the project and where we can use patterns is more interesting and will have a much greater impact than unnecessarily restricting ourselves to just the 15% devoted to design.

We can also embrace the PBE Core Value “Make your patterns live” as we create patterns. We may start out with a specific aspect of the design or the code. However, we don’t want to stop at this point. Once we have built the initial pattern, we need to put thought and effort into figuring out how we can add more responsibility and “scope.” In the case of a code pattern, we can start to think about generating related test cases, associated documentation, deployment scripts, and so on. In this way we start to address the other tasks that we need to accomplish when we deliver a software application.

Some of the PBE Patterns and Guidelines that can help you get beyond a design-only mind-set include Antipatterns (Chapter 11), Determine Business Impact (Chapter 11), Domain-Driven Patterns (Chapter 10), End-to-End Pattern Use (Chapter 10), Refactor with Patterns (Chapter 16), and Use Pattern Definitions to Understand Existing Solutions (Chapter 16).

PBE Is Only for Forward Engineering

Related to the previous misconception, we find that some will use patterns only for forward-engineering a solution. As Figure 19.2 illustrates, there are a number of different pattern use cases⁴ that we can leverage within PBE. Patterns can be applied as in the common forward-engineering approach, but they can also be harvested from existing applications. Other uses include detecting pattern occurrences within existing code and using patterns in refactoring.⁵

Figure 19.2. A single pattern definition supports multiple use cases.

Ideally, we would like to use a single pattern definition to drive each of the use cases, allowing us to get a better return on investing in a pattern. While this is possible for pattern specifications, unfortunately today’s tooling is not quite at the point of making it possible for us to develop a pattern implementation and use it as input for these different use cases. However, the good news is that with the extensibility of modern IDEs, Eclipse particularly, we can still leverage these use cases, at the cost of creating different pattern implementations. For example, we can use the Architectural Discovery feature of IBM Rational Software Architecture to analyze a model or code base and identify occurrences of patterns.

Some of the PBE Patterns and Guidelines that can help you get more from your patterns include Antipatterns (Chapter 11), Refactor with Patterns (Chapter 16), and Use Pattern Definitions to Understand Existing Solutions (Chapter 16).

Guilty by Association

Some still question the value of using models and modeling languages to simplify development. They are comfortable and familiar with code and prefer to continue just using code, not trusting modeling and any associated generation capabilities.⁶ PBE and MDD are complementary but are not coupled. The choice of one does not automatically require the use of the other. We can adopt an MDD approach without using PBE and vice versa. For example, we can use pattern specifications as blueprints to help us design solutions.

When using pattern implementations, we don’t necessarily need to use UML or even visual models. We definitely need to develop an input model that will allow us to apply the pattern and generate output, but this model can be represented using a DSL or something as simple as an XML file. Remember, a model is just an abstraction of reality, where we hide unnecessary details. We can represent such a model in many different ways.

Some PBE Patterns and Guidelines to consider include Integrated Patterns and DSLs (Chapter 15), Model-to-Text Pattern Implementation (Chapter 13), and Simple Solution Space (Chapter 10).

PBE Requires Tools from a Specific Vendor

A final misconception is related to tooling and vendors. Some come to believe that following PBE requires tools from a specific vendor.

A first step in addressing this misconception is recognizing that we can leverage PBE without using any tools. We can receive many benefits from following PBE, even if we are not using automation via pattern implementations. If we want to use pattern implementations, a number of different options are available, from the open-source community as well as commercially from software vendors. Appendix C provides an overview of some of the different tooling options.

One issue that does arise is that pattern implementations have not yet reached the stage of open standards and specifications. A pattern implementation that is created in one tool cannot be used directly in another tool. Of course, pattern specifications are tool-agnostic, but implementations, once built, are connected to a tool.

Some PBE Patterns and Guidelines to consider include Antipatterns (Chapter 11), Communicate Design with Patterns (Chapter 16), Pattern Specification (Chapter 13), Refactor with Patterns (Chapter 16), and Use Pattern Definitions to Understand Existing Solutions (Chapter 16).

Summary

PBE is practical and pragmatic and can be adapted to the level of formality and automation you need. It is not only about design and automation; we can use patterns (specifications and implementations) to help with assessment, environments, and deployments. We can foster creativity while taking on risk and tackling troubled projects. And last but not least, PBE is not restricted to an elite set of users. Anyone with the ability to observe, identify, and synthesize while working with recurring problems and common solutions possesses the fundamental skills to practice PBE.

With PBE skills and knowledge, an awareness of misconceptions, and how we can remedy these issues, we are ready to move forward. We can successfully adopt and grow PBE within our team and organization.