Patterns pitfall

I’ve seen a number of posts recently both supporting and criticising Team Topologies and Dynamic Reteaming. I didn’t write either so I can’t say for sure what was intended. What I have observed though, is they’re essentially patterns books.

Like other patterns books, the problems I see aren’t so much with the book as the misapplication of the patterns (yes, we’re “doing it wrong”). In my experience, people tend to read patterns books and feel the need to apply every pattern. They want one of everything.

I’m old enough to have experienced this first hand with Design Patterns and Analysis Patterns in the mid ‘90s, and again with Patterns of Enterprise Application Architecture and Enterprise Integration Patterns in the early 2000s (guilty as charged, your honour!), and I’m seeing it happen again with Team Topologies and Dynamic Reteaming.

I don’t think I’ve read a patterns book and thought the patterns were right or wrong. They’re usually descriptions of useful ways of approaching various problems, or in some cases simply observations of how people have solved them. Frankly, they all look appealing in some way, and that’s part of the challenge: patterns are heavily context dependent, and adequately conveying that context through a book is difficult.

Do you need a factory, or a unit of work, or a tiger team, or a platform team? I have no idea. I do know that just because a book talks about a pattern doesn’t mean you should use it.

Understanding patterns absolutely helps us understand the problems we want to address, identify the patterns we’ve already implemented (not necessarily by design), and compare that to what we think we need.

Above all, resist the urge to have one of everything.

UPDATE 1: John Cutler prompted me to point out that I’m absolutely in the loved Team Topologies camp. It’s one of the books I regularly recommend people read.

UPDATE 2: Peter Sommerland pointed out I’d missed an important and influential series, Pattern-Oriented Software Architecture.