Summary: Patterns give devs a language for collaboration Lean-Agile puts a premium on collaboration. We always talk about increasing the bandwidth of communication: between customer and developer, between members of a development team, between your team and other teams, and, indeed, between various generations of a team (why did they do it that way?) Gone are the day of a programmer sitting alone in cubicle; most developers find themselves as part of a team. Now, it has always been easy for developers to talk about implementation. We have coding structures and algorithms. All very precise and widely understood. But it has been very difficult to talk about design. Sure, we have UML diagrams and specifications and requirements documents. But, they don't really get to the essence of the thought behind a particular design. That is where patterns come in. Patterns give us a language to talk about design ideas. Each pattern is a shorthand for a bucket of forces and principles and constraints and the costs involved in the pattern. When I say I used a Decorator here, you can know what is expected and we can talk about why it was chosen and the rationale for what went into its particular implementation. We can discuss the tradeoff of this approach vs. that approach based on the pattern's cost. This is how professionals talk to each other. But not only within a team, patterns allow you to access the knowledge of a larger community of professional developers. If you are working on a particular design and discover part way through, "this looks like a Bridge", then you can turn to the Bridge pattern and see what else it is telling you should be there. It can accelerate your rate of development by predicting the elements that must be in your design. Now this works as long as you can see a pattern as the shorthand and remove yourself from a particular coding implementation. Too many patterns courses and books dwell too much on the implementation, and you lose the essence of - and thus the real power behind - the pattern. A central repository of patterns Now, for patterns to become a useful language, everyone has to have a common understanding of what they are about, what they mean. There is a large number of patterns and they grow as we learn more about them. What is needed is a central repository where we can talk together about the patterns. There are other pattern repositories, but none of them talk about patterns in the way Scott is talking about them: as a language, as a collection of forces and language elements. All of this has led Scott to create an open repository with this in mind: http://www.netobjectives.com/PatternRepository/. This is a community-based repository, sponsored by Net Objectives. You can read for free. Or if you want to contribute, you can register and become an editor, much like the wikipedia does. Net Objectives is sponsoring this because it brings value to the community. And that is one of the central tenets of Net Objectives. Emergent Design To complement this work, Scott is working on a book about Emergent Design, which covers two points Designs emerge The need for developing a professional language This book is out for review, to good response right now. The book helps get people ready. The repository then grows the community. He is also working on a course on these ideas. 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 PatternsThinking, 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 Getting an Agile team started in patterns In the future, I will try to get Sco
