At the p&p Summit last week Jason (The Hogg Blog), Ade (#2872), Dragos (Dragos Manolescu's blog) and I staged a discussion that was designed to polarize and divide the audience along "patterns vs. tools" line. Jason describes the event (The Hogg Blog)and J.D. adds interesting remark in (Patterns vs. Tooling).

On stage we intestinally took inflexible, all-or-nothing positions. In reality we all believe, at least I do, that tools and patterns complement each other. For example, on the following day I gave a presentation on "Patterns of Software Factories" in which I showed how the p&p factories (smart client, web client, web service, and repository factories) use patterns to build what they build. I have identified over 20 major patterns and showed how the factories put them together and implement them.

My key point in the discussion, and the thing I believe in, is that most useful are instrumented (encoded in tools) collections of carefully selected patterns that together build parts of applications: composite clients, WCF services, data mapping layers, etc.

Libraries of pattens, like Pattern Share, suffer from two major problems:

  • it is difficult to map a large design problem onto a collection of patterns that if put together will address is, and
  • the distance between the pattern description and its running implementation can be large.

Even the current, initial versions of factories address both of these problems; they come with pre-selected patterns and they come with tooling to commit those patterns to code. The major shortcoming of the current factories is that if the selected patterns don't exactly fit your needs, they (the factories) are difficult to change. But this is a subject of a different discussion.

Bottom line, I don't believe that this is "either patterns or tools" situation. On the other hand, today I will put my money on instrumented collections of pattens that do something, over an open-ended library of patterns.