Calibrating pattern language and specificity

[tony_ln]

I’m experimenting with pattern language to describe our next project. The second sentence of 3.4 feels like the right level. Hopefully, this conveys trust to people “walking the land” to make a call when they implement the relationship Vs ambiguity. I’m still calibrating .

In trying to instill this ethos I’ve been saying, “maker’s choice” to indicate as long as the relationship is satisfied, do what feels right (vs trying to predict upfront what will feel right). I’m finding this is where Shape Up and Pattern Language work beautifully together.

I’ve a long way to go to sharpen my pattern language/shape up technique but so far it’s been useful. ICYMI: Here’s the video of RJS talking about pattern language for a specific feature in BC4 Case Study: Shaping "Introductions" for Basecamp 4 and Writing a Pattern Language on Vimeo

[JoshAntBrown]

Thanks for sharing! Really like the “maker’s choice” framing.

The Pattern Language stuff works so well for Shape Up, I’ve really been enjoying putting it into practice. One thing that I’ve been doing that I’ve taken from the book “A Pattern Language” is using the word “Therefore,” in every pattern. I find it creates a forcing function to make sure I’m sharing the context around the form that I’m proposing. Helps me identify all the forces acting upon that pattern.

What I think is really nice about this pattern language/shape up stuff though is it’s learning curve. The format feels easy to get into but the balance of shaping work at the right level of detail so it’s not overly prescriptive but instead descriptive of the work is a tricky one to master.

[justin]

I’ve been taking a similar approach as a way to augment my pitches, and have tried to use the language to always indicate that I’m expressing relationships (between the user and the product, or between two distinct areas of the product, etc.) rather than requirements.

I’ll point out one difference I see in our approaches. When I write patterns I title them so that if the only thing someone reads is the title (what’s in bold), that’s the key information about the pattern. When the project is shipped, the team should be able to argue that each pattern is “true”. What’s after the bold is auxiliary information simply meant to distill further understanding about the language. It’s suggestive but needs to be discovered.