This book is about software development process. I guess it's aimed at project leads, project managers, and managers. But it's organized into Design Patterns, a form loved by many computer programmers. So I guess it's aimed at leads and managers who come from a programming background. Still, I'd hesitate to drop this book into the hands of a recently-minted manager who used to be a programmer. Though this book claims to be design patterns, it reads more like a "bag of tricks". A good bag of tricks is a wonderful thing. But if you don't tell folks when it's appropriate to use those tricks... Well, you've given someone a bag of hammers, but they can't distinguish between types of nails.
Some places in this book talked about "symptoms". But not all. And mis-applied software design processes can grow awful in a hurry. The authors have seen this:
Most process-intensive organizations look to a process specification document as the final word on development activities. We noted three problems with this approach in practice:
- lack of empirical conformance between practice and process specifications
- incompleteness of process models, and
- inability to capture long-term stable process abstractions.
So... how to present this material to a wet-behind-the-ears engineering manager? Maybe don't show it to them at all until you're sure they're ready for it. Or maybe only show those patterns that have "smells" to go with them.
It's not always clear what the authors are trying to say. They try to find generic names for things. This prevents false recognition, yay. On the other hand, it also hinders recognition in general. In their scheme, I am a Mercenary Analyst, but I didn't recognize myself in there at first. So, as the book threatens, you'll want to make your own pattern language, stealing ideas from others' languages, but reflecting the state of your organization.
But don't be too eager to do so. After reading this book, I googlified teh internets to see what other people had to say about organizational design patterns. And of course there were many many people saying "Here's my pattern language for software development organizations." Which is fine as far as it goes. But if you find yourself tempted to write yet another one... Well, just beware of time-frittering. (Yes, yes, every organization is going to have it's own pattern language. Yes, yes, Alexander tells us that we must develop our own pattern languages. And yet... yet... when I look at all of these pattern languages out out there, I smell time-frittering.) How to make a "local pattern language" useful? I think that the secret is to use local examples. E.g., when the authors said "Mercenary Analyst", I didn't know what they meant. But when they mentioned that Betsy Hanes Perry was their favorite Mercenary Analyst, that helped a lot, because I've seen some of Betsy Hanes Perry's work.
So... it's good to work on your own pattern language because you can talk about the local variations. But it's also an opportunity to, uhm, un-universal-ify these "universal" examples. Make them more specific; cite examples from your organization; use language that folks will understand.
