The Great Debate: Patterns vs Tooling

With well over 250 attendees this years P&P Summit is the best attended I have seen so far. I was fortunate to participate in two presentations - the first talk was on SecPAL which I believe was well received, and the second was a discussion with myself, Dragos Manolescu, Wojtek Kozaczynski and Ade Miller on the future of patterns.

As you may recall the 4 of us worked on a paper called “The Growing Divide in the Patterns Worldfor an IEEE special on design patterns. Our article summarized results from a survey about the relevance of patterns for several hundred developers. One of the not surprising (or perhaps not unsurprising) results that we saw from the paper was that for many people simply with including patterns in tooling was sufficient and that they did not see significant value in traditional narrative based patterns. 

So, with our goal being to find a controversial subject that would encourage audience participation (and perhaps more importantly) provide feedback that will drive P&P's future investments in the pattern space we decided to use the P&P Summit as a forum for discussion about the extent to which P&P should share patterns via books or Pattern Share - or whether they should focus purely on including patterns inside factories. 

Myself and Dragos were in the red corner, advocating that patterns should first be written in the narrative form, whilst Wojtek and Ade took the blue corner arguing that this format is irrelevant and that the majority of non-academic folk only care about productivity and tooling. The discussion started off with a curve ball. I had expected Dragos to have a strong opening statement that would incite hatred amongst much of the audience, instead he punted to me - leaving me to take the rubber bullets from the audience (Keith Please had armed the audience with toy guns so as to shoot people that they disagreed with). 

Rather than making Wojtek and Ade's job way too easy, I decided to argue that tooling should only be based on patterns, and that tooling based on patterns was inevitable. As such I argued that it was critical not to lose site for the need for crisp architectural guidance articulated in pattern form that can be shared in books, web pages and hopefully organized dynamically on resources such as Pattern share. 

I have to say that the discussion was fantastic mainly because the audience got so involved in the discussion. We had advocates on both sides of the audience. Some common themes discussed (liberal paraphrasing) included:

  • Many enterprise developers do not care about design patterns - they just want to do their job

  • Enterprise architects have a hard time communicating the value in patterns to their development teams

  • Patterns do in fact play a critical role in application architecture and P&P should continue to create and publish patterns independently of tooling

  • People do not want to have to download factories to determine if there are patterns that are relevant to their problem

  • Patterns should be consistent across programming platforms

  • and much, much more...

I have some additional thoughts on the subject which I will share in the coming days as well - but first I wanted to see if we can't get some additional discussion going.

So, if you were in the discussion, feel free to post additional thoughts, or if you weren't there it would be great to hear your thoughts on this very important topic... To what extent should P&P invest in publishing patterns independently of tooling such as Factories - and would you like to see a reincarnation of the Pattern Share repository (friendlier UI etc)?


Comments (5)

  1. Jason,

    REALLY sorry that I missed that discussion (Alas I was not able to get away to be as the Summit). I have to chime in that I firmly believe that Patterns in (well written) Narative Form are critical.

    Without this initial phase (i.e. prior to the patterns being implemented in tooling), it is virtually impossible to evaliate their merit and perhaps most importantly their potential interactions with other patterns.

    As a consulting architect, I do agree that it is sometimes difficult to convince a team of the importance of understanding Patterns (not just "What", but "Why". This "WHY" part is no possible if the pattern is simply embbedded in tooling.

    Keep up the great work. I have nearly the entire P&P book library (in well worn condition) and typically have my clients get them as well.


    David V. Corbin

    President / Chief Architect

    Dynamic Concepts Development Corp.

    New York, NY

  2. I’m a fan of patterns. I think of patterns simply as problem and solution pairs. I wandered by The Hogg

  3. J. Schuetze says:

    First off, shame on the guy who started shooting you in the head every time you opened your mouth to speak.

    There was some good discussion during this session, and ultimately I ended up more torn between the two sides than I started.  I like the idea of embedding the patterns in the tools, but I think there are several downsides, and for that reason I was initially against doing it to any great degree.  There was one example Dragos used of his child putting the keyboard on auto-play, and not learning anything about how to play by doing so.  There was some strong reaction to that, but what I didn’t get a chance to say was that it goes beyond the child’s lack of learning.  If a child picks a certain background track to play with, there’s only an aesthetic impact on the result, if a developer or designer picks the wrong design pattern there may be a HUGE impact.  Tell someone to pound in a nail and give him a toolbox of heavy tools he doesn’t know how to use properly, and he’ll beat the nail in with the first Pounder he finds.

    This really is the downside of patterns in tooling, as far as I’m concerned.  You give someone a toolbox of very powerful (and dangerous!) tools and people will get hurt.  It’s not unlike if I were to sell dynamite with nothing other than an admonition to "be careful!".  There’s a reason the average joe can’t just go buy dynamite.

    I liked your idea, at the end of the session, of having a way to hook patterns into the tooling more easily.  Your comments were short, and we were running out of time, but ultimately I envisioned something like a way to plug in patterns to VSTS as they were added to some kind of public repository, and personally I also envisioned something along the lines of a menu item or wizard that would take you to the website, explain the pattern, then have a ‘click here to use this pattern’ type of feature which would create the stubbed classes for the developer.  It could even be setup to only do the explanation/overview on the first use of the pattern.

  4. Jason Hogg says:

    The guy with the gun was kind of annoying – but our greatest fear was that the event might end up making us look like academics sitting in an ivory tower – so the guns were meant to be used as a means of grounding us!

    Myself and Dragos were given the role that could have made us out to be academics, which is why I tried to focus on the importance of continuing to support the narrative form – regardless of how the patterns are then used.

    I understand the points you are making about people getting hurt. Our intent with the factories was that there would be an evaluation phase where an enterprise architect / lead developer would review the solution and customize it according to their organizations requirements. Since I left P&P I do not have data on whether that happens or not.

    Another interesting point to consider would be – which is worse:

    a. An application with no architecture,

    b. An application that is over-engineered for a specific instance of that application type

    c. An application using patterns that have been mis-applied…


  5. Frank says:

     Hi all, I’m a solution architect from China. I found this topic very interesting and I want to share you with my thoughts.

     My opinion is that the development of patterns and tools are independent from each other.For different people, there might be different concerns.

     As you all know, China is becoming the biggist ODC market for outsourcing projects coming from all over the world. I most of the outsourcing companies here, productivity is the most important. The employer need their projects be well and quickly maked.They don’t care too much about whether their developers had learned or not the design patterns from the projects, because they are concerning about the profits. For sure they prefer well decorated tools. On the other hand, the developers need to learn patterns well in the first place because this increases their personal values a lot in their career life, and could help them to find better paid jobs in the future.

      So if this debate takes place in China, I think most of the employers will stand on the bule corner while the employees stand on the red corner.

Skip to main content