Embrace Change through Patterns

Perhaps one of the benefits of Agile is that you can get frequent, almost constant validation of what we are doing. In waterfall approaches, it too often happens that after a Plan-Do-Review cycle, the review results in bad news: something is wrong. Now, we have to go back and re-work a bunch of stuff. That is wasted effort.

In Lean-Agile, we try for more frequent and early approvals. We recognize that developers almost never get it perfect the first or second (or third) time through. We recognize that the Business needs to change the system to respond to current conditions or as they learn more about what they need.

We want to embrace change, but it comes with a cost. Lots and lots of change can be demoralizing if it causes a lot of re-work all the time. How can you embrace change without overwhelming the team?

Patterns and Test-Driven Development address this issue. They are based on the premise of the Open-Closed Principle, which implies that if change is a problem for you, then change the rules.

• Patterns guide you to set up your environment so that, when change comes, you can accommodate it by adding something new rather than having to re-work something old. The impact on the overall system is much less.
• TDD helps you work in very small increments, allowing you to defer commitments to one design choice or another while you are still learning about your system. Make your commitments when you are smart, not when you are still ignorant.

Together, they make change much less expensive and much easier to accommodate change. This is critical to Lean-Agile where we are trying to embrace, rather than prevent, change, as we try to create products that track with what customers truly want, and as we learn together what we want to do.

How do patterns do this? Due to Open-Closed, they encapsulate variation, which means that you can contain the variation happening to your system. Containment reduces the overall impact. Each pattern addresses a different type of variation, each pattern allows me to be open-closed about some type of variation. For example,

The Strategy Pattern encapsulates the variation of a single algorithm. If I get a new version of that algorithm, then I can introduce that variation without having to change the system. The Strategy Pattern hid the algorithm in an abstraction.

The Decorator Pattern allows you add many behaviors on top of a base behavior (for example, think about filters on a camera). Decorator allows you to hide, or encapsulate, or be Open-Closed to the types and number and order of these behavior.

Creational patterns allow you to encapsulate the ways in which objects are instantiated, allowing for changes in the future to the way you create objects.

What is interesting is that this way of thinking about Patterns is not really in the Gang of Four book. But it is crucial to understand if you want to do Lean-Agile in a sustainable way, so that you can plan for change. You want to be able to think about which patterns you should use (and which to ignore for now) to allow for change.

Learning While Doing

Both Lean-Agile and waterfall have a Plan-Do-Review-type cycle. There are two primary differences between them.

• A matter of scale. Waterfall iterations are so big that the changes tend to be quite large.
• A problem of mapping. Waterfall was created for an engineering project where compliance is very important and where change is quite hard and expensive. Software is a creative process. You discover much by coding things, doing things.
• An unnecessary constraint. Software is easy to change. We want to allow change to happen. It is why we call it software.

A podcast series with Scott Bain

This podcast continues a series of conversations with Scott Bain, a senior consultant and one of the premier experts in patterns and test-driven development. He teaches and coaches three Net Objectives courses: Design Patterns Explained, Advanced Software Design and Test-Driven Development. He has thought deeply about patterns and Lean-Agile.

In this introduction, we cover:

• What are design patterns (and what are they not)
• Are design patterns still relevant?
• Patterns, TDD, and change
• Patterns as part of the language of professional developers

In the future, I will try to get Scott back to work through an example.

Recommendations - Training by Net Objectives

• Design Patterns Explained
• Advanced Software Development
• Test-Driven Development

Recommendations - Reading

• Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott

Music used in this podcast:

• “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com
• “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/

For more information, contact [email protected] or visit us at http://www.netobjectives.com/