I often see Martin Fowler’s works strewn around ThoughtWorks offices and client sites. Maybe it’s an unwritten law of ThoughtWorks that the development message of the organisation is especially embodied in his works. We certainly don’t promote his works internally of externally. They just seem to crop up - no doubt it helps to be one of the most successful publishers in recent times.

Analysis Patterns, (his first publication) is however a book that I’ve never seen piled around the offices of my lifetime. I’ve only heard it whispered occasionally and referenced in DDD. In essence, it’s seemingly barely of any practical value 10 years on from publication. I’d been warned it was a heavy read; detailed, complex and confusing. Something where your attention factor tends towards zero fairly quickly.

After reading and gestation time (with a honeymoon thrown in), I can’t deny all the negatives are there.

Fowler does warn that cover-to-cover for this book doesn’t work for all. As the patterns are so domain specific, nowhere near as generic as GoF, ones ability to digest the patterns is severely dented. Still, as Fowler convinces, patterns for some domains provide insights into others - so cover-to-cover it was for me.

A painful 8 months later and I’m at the end, seemingly not much more the wiser for the effort. The content was so heavy that roughly 7 pages was, in all seriousness, my largest uninterrupted reading sequence. My re-read rate was also probably an all-time high. I guess since this publication Martin’s learnt to be terser.

But there were some highlights.
Being a tad sarcastic; the nostalgia of examples in Smalltalk, some recipes based on superseded language features/restrictions like pointers and memory management (or lack of), some extremely confusing diagrams and notations (pre UML) and the prospect of patterns maturing into libraries (an industry-wide plague at the time).
Being a tad more serious; his exploration of the design options were insightful.

Significantly the book also provides a detailed explanation of the ‘knowledge level’ mentioned but not explained in the latter chapters of DDD. The importance of this concept cannot be understated; it pervades through a fair chunk of the patterns and deserves a larger influence in everyday design. DDD certainly continues on from Martin’s discussion of the fundamentals; values and entities, associations, equality etc. all get a mention. While we’re on the subject, I’d recommend DDD above Analysis Patterns as it focuses on the generics for modern languages (maybe they were 3 years ago) and is a much simpler read. But the heart of Analysis Patterns, its focus on specific domains, strangely enough gives generic insights not captured in DDD – I guess it’s the kind of stuff you can come up with after knowledge crunching for a while. For that reason I expect it will be enduring reference for all domains I encounter – so I guess it wasn’t a fruitless exercise after all.

In all I wouldn’t recommend wading through each page as I endeavored, hoping to stumble across a serious nugget. I would recommend reading through the pre-pattern content, and gathering a sufficient enough understanding of the domains to aid future reference. Of course, mileage may vary.

A concept is born. It’s then quickly labeled.

Inevitabliy sometime later it’s misinterpreted and and misrepresented. The label is used for other purposes. Inevitably, it’s bastardised and the concept blurs.

So it has been with Refactoring. So it has been with Agile. Sure, go ahead, call it re-designing. Call it anything you like.

The fundamental issue remains; a lack of understanding.

Time and time again I’ve found this the most essential question in employee/organisation reviews. It’s a superb question to identify those values and skills most significant to the respondent.

The more respected the respondent the more significant the response.

The more significant the response the more likely you are to change behavior.