Coplien and Harrison have spent over a decade studying software development teams in the wild. In Organizational Patterns, they present their findings in four interconnected pattern languages: project management, people & code, piecemeal growth, and organizational style. Organizational Patterns models itself after APatternLanguage, following the "Alexandrian" pattern format very closely.
The authors quickly admit that the inclusion of the term "Agile" in the title was almost solely for marketing purposes: "This book covers topics broader than so-called agile development. ... While many of these patterns contribute to agility, our chief aim is effectiveness."
I'm midway through the book and have found it valuable so far. For me, two attributes of an effective pattern language are sequencing and naming. Coplien and Harrison cover the concept of sequencing in chapter 2: "Sequences unfold as stories... If these patterns really do belong together, then we should be able to come up with a story that flows through the patterns." Naming the patterns is a powerful act, especially when a pattern language is well received within its field. It provides people with a unified vocabulary to describe with a simple phrase what would have previously taken a paragraph. Organizational Patterns possesses both of these qualities.
My two complaints so far are that the pictures are lame and the writing could use more color...I have found the book to be a bit dry. --DaveHoover
What Dave said.
Plus the organizational patterns all resonate, evoking that recognition that goes with something you've been using for a while without all the precision, insight or a name. I'm having a lot of: "Well yeah. And here's a time when we did something like that . . . "
One nit to pick, a general gripe about the patterns literature that this book shares. The presentation of patterns in general is pretty weak about counter-indicators, and assessment down-stream. I'd like to see the benefit of experience extended to: " . . . and when this happens, it's doing its job - meaning you guessed right." I'd like to see: "Don't even try this if this, that, or the other are going on."
For example, many of the GoF patterns look to me (I am speaking from ignorance here. I am not an OO or patterns expert, nor do I play one on TV. I'm just trying to use the stuff.) like ways to allow mutability, without risking correct function, in the presence of a strong, static type system in the language. If so, then you'd say: "This pattern was a good choice when you experience a bunch of "adding functionality to objects" changes down the line (For decorator, more or less), and those changes are drop-in functional additions and that's it." Similarly, the implementation was well done when the right kind of changes are easy to implement as they should be with this design. A design pattern sort of anticipates a kind of change over time as part of its rationale. Whether that's what's happening, well, you don't know until later. Whether you built it to realize what the pattern can give you is another thing you don't know until later.
I'm much more concerned about counter-indicators and how to know when something is working when we're dealing with the organization vs. the system being developed. Having dross hanging out in your organization generates a lot more consequences than code-dross. Code-dross tends to mostly lie there until poked. Not good, but kind of passive. Organizational-dross has in it active people who do things. Much more disruptive, and kind of unfair to the people involved.
Or am I asking too much here?
![[Home]](/wiki.gif)