« Yo Ho, Yo Ho | Main | Turn over enough rocks... »
July 21, 2005
Patterns Patterns Everywhere
Late last year, before we moved, a colleague loaned me a copy of Organizational Patterns of Agile Software Development and suggested I read it.
It promptly got lost in a pile during our move into the house, and finally surfaced at the same time I found The Party's Over (also loaned to me, by a different colleague). I finished it on the ferry this morning.
Overall, I thought it had some gems in it. It's hard to judge a pattern book based on the "merit" of it's patterns - you don't (can't?) know if they "work" until you've applied them in a given situation - but many of the patterns enumerated in the text have a ring of truth to them.
I found the book to be less "satisfying" than a software (design) patterns book - and it took me a while to realize that my discontent likely stems from my lower familiarity with organizational issues. I know what works when it's working, I know what doesn't work when it's dysfunctional, but I've not spent much of my career this far focused on "pure management."
The book concludes with chapters on when to apply the patterns (the organization I work in is probably not ready), the anthropological foundations of the methods used, and two case studies (of the Borland Quatro Pro 1.0 team, and of an unnamed team within AT&T).
To get a taste of the content and style, you might check out this paper, written by the same authors, appearing in the Summer 1996 Bell Labs Technical Journal.
I found two things consistently irritating. First - the authors consistently propagate the stereotype that "software engineers can't communicate" so, they conclude, don't make them. Hire technical writers to write design documents and technical specifications.
Even assuming that software engineers can't communicate effectively, the idea that you can solve the problem with more bodies has several problems in my opinion and experience. First, to adequately document design and structure, the technical writer has to understand what they're documenting - so they need to be at least as smart as the engineer they're shadowing (smarter really, 'cause they also need to know how to communicate). And the engineer still has to know how to communicate - the writer isn't going to gain the insight they need by divine intervention. If the communication is verbal, then there are schedule problems (the two need to be "face-to-face"). Alternatively, if the communication is written (or email), well then don't look now, but the engineer is communicating. Whatever will we do.
Second, and more philosophically, the idea that software engineers can "get away" for the bulk of their professional lives without producing technical documentation (we're not talking about user-level documentation here, we're talking about design documents and technical specifications - the why behind the what and how) is offensive. No true (accredited?) engineering discipline is satisfied to allow it's practitioners to hide behind "poor communication skills" as an excuse for not documenting their designs and work-products.
But that's just me. And I'm writing this entry. In english. So I guess I'm not the target audience.
Posted by dberger at July 21, 2005 8:59 AM