Friday, October 16, 2009

Patterns and Frameworks

I just returned from the Microsoft Patterns and Practices Summit 2009 which may be my favorite Microsoft conference. Great for exposure to customers with real applications and to the wonderful, dedicated Microsoft developers who aspire to serve them. More on this in another post. I have another point to make here, which is …

Patterns are not Frameworks. We should draw a bright line between Patterns and their Implementations. A pattern only becomes a pattern if and when there are multiple implementations. You don't know a pattern well until you've seen more than one implementation. If there is a single, canonical implementation, the thing is not a pattern, it’s a framework.

“Duh” you say. We know this. And yet it eludes us in practice.

I had numerous conversations about this with folks who work in PnP. The conversation goes something like this:

The Conversation

“We are not a product group. We don’t want to be a product group.

“We’re trying to provide guidance to consumers of Microsoft development products. We are reluctant even to say ‘best practices’ anymore. It’s just the best guidance we can give today, built with time, and commitment, and our access to experts inside and outside Microsoft.

“We’re answering the customer call for Microsoft to demonstrate how to use its own products in real applications.

“This bleeds inevitably into more general questions about how to build applications and soon (and properly) we investigate and describe general design and implementation patterns that go beyond the particulars of Microsoft products.

“It’s not enough to talk about the patterns. We need to demonstrate those patterns … express them in real code that works with Microsoft technology.

“That is when it starts to get away from us. Our guidance, as it becomes code, starts to cover more and more customer cases. It begins to harden and the pattern becomes harder to see behind the bells and whistles. Customers say ‘wow, can I use that in my application?’ and we say ‘sure’. They say ‘it would really help our particular situation if it also did this’ and we say ‘sure’ again.

“Then they want us to give it a name, package it up, support it, develop a roadmap. They want us to productize it … and we start to do that because serving customers is also our mission. And, in our (not so) secret hearts, we all want to ship products … we’re wired that way.

“Then we start worrying about backward compatibility … because customers get angry at us if we change anything

“Then others in the community, especially the Open Source community, get on our case for having sucked the oxygen away from alternative implementations that may be better in many scenarios. They say we have imposed, de facto, a particular implementation of the pattern; people can’t tell the difference between the pattern and what Microsoft did to it. And I see their point.

“And now we have old code (e.g., CAB) that no longer represents our current thinking … that, in fact, embodies practices we would counsel against today … and we cannot walk away from it.


I don’t know that there is an easy answer to this one. I’m not willing to place all the blame on PnP either. The customer should know better.

“Best Practices” do not sit still. They evolve, leaving behind a trail of “formerly best practices” to which millions of dollars and entire careers are firmly attached. PnP is pulled in one direction by its responsibility to offer the best current guidance … and by its responsibility to customers who have placed big bets on its past guidance.

Perhaps we need some different rules of engagement.

Explicit Shelf Life

What if PnP put a “Sell By” date on their code? What if it had a shelf life and warning label: “Use with caution. Do not expect support beyond 3 years”. Stamp this at the top of every piece of code and every web page.

Then mean it. If you need to break, you break. Customers need to know that you are serious about your commitment to giving them the best advice you can and you do them no favors by clinging to outdated code.

This happens in OSS all of the time. Dead bodies are strewn everywhere.

You can do this. Microsoft can’t but you can. I think you can wean your customers away from thinking of you as a product group. If that means fewer customers served … that may be for the best … for everyone: your customers, you, and Microsoft itself.

Play Well With Others

My thesis again: a pattern is independent of any one implementation. You don't know a pattern well until you've seen at least two implementations.

What if PnP routinely called out the other implementations of the patterns they describe? Front and center, not as an afterthought. Openly encourage customers to look at these alternatives … if only to gain a contrasting perspective on the PnP guidance.

One of the best ways to learn about the Composite Application Block (CAB), for example, was Jeremy Miller’s “Build your own CAB” series. I assure you I had no intention of following Jeremy’s advice and building my own CAB. It didn’t even occur to me. But that series was the best (unintentional) documentation of CAB I ever found, It introduced me to different ways of thinking about each issue (e.g., Event Aggregation and Dependency Injection). I learned indirectly what CAB was doing and the consequences of my choice. I’m not saying the consequences were all bad either; but there were consequences and I only recognized them in the oblique light cast by Jeremy’s series.

PnP might do more to highlight these alternatives and to encourage discussion about the contrasting choices. People who come to Prism should learn … right there on the home page … that a Caliburn exists. When they come to the Unity home page, they could learn that there are 5 to 10 other popular IoC containers to choose from and find links to learning more about IoC practices.

[I was just on the Unity page. It’s a fine product home page; it is not fine for guidance about Dependency Injection and IoC in general.]

I don’t think that PnP should endorse Caliburn or anything else for that matter. I’m not suggesting that PnP’s output is inferior or that PnP should express less than abundant enthusiasm for its own work.

I am saying that PnP is presenting itself as a product purveyor in a manner that conflicts with its role as a trusted source of guidance. This ensures that it will be trapped into long term support commitments, the kinds of commitments that some people there tell me they do not want.

PnP could say in some unambiguous fashion, “my dear customer, we offer a wonderful implementation of this pattern. HOWEVER … you ought to look at some alternatives, not only when first choosing your approach but also throughout your application development; there’s gold in seeing how others approach these same problems.”

True Open Source

What if PnP could accept contributions from the field? I don’t mean through “Contrib”; I mean directly into the guidance itself.

What if PnP developers actually read some of the Open Source code out there?

I’m pretty sure the legal guardians won’t permit it … in which case “Contrib” is the best they can do.


They call it "Microsoft Patterns and Practices", not "Microsoft Tool and Die".

It is time for customers to pull back from unrealistic expectations of Patterns and Practices. They are not your application infrastructure outsourcer. They are a trusted source of guidance. Rejoice if they provide more but do not expect or demand it.

Patterns and Practice doesn’t need to change what they build. I do think PnP can rethink its commitments to prior output. It can do a much better job of promoting the spirit of exploration and directing its community to external resources that offer contrasting implementations and points of view.

And now I descend from this soap box … in search of another.


David Nelson said...

Very well said, and I wholeheartedly agree. PnP should not be a product group, and yet they are. Very few people would describe Unity as a guidance project; most would call it an IoC product in competition with other products. This leads to the kind of support and backwards compatibility issues that you describe, which prevents them from moving forward and updating their guidance to keep pace with the world.

Bakopanos Konstantinos said...

Nice post Ward!
I had a discussion with some of the p&p folks and they claim that the majority of their "users/customers/community" uses Ent Lib, Unity and Prism out-of-the binaries.
Personally I only use Unity this way... for all the rest I simply copy code and ideas.

J. Ambrose Little said...

True that on the patterns thing.

I think MS needs both PnP "products" and the sort of more peer to peer guidance you're advocating.

Anonymous said...

Great post, Ward. I agree completely. Too many clients I have come across take these guidance projects as "Microsoft Gospel" and refuse to see how other alternatives could possibly be better.

Ward Bell said...

Thanks, friends.

Costas - Yes, the PnP constitutency is grateful for PnP "product". I am grateful for PnP "product" which I use and which my customers use.

There is nothing inherently wrong with PnP delivering the likes of Enterprise Library and Unity and Prism.

My thought is a different one. I am suggesting that we, the PnP customers, wean ourselves from our expectation that PnP should behave like a Microsoft product group. PnP should be free to re-boot or walk away from one of its titles when that makes sense.

I'm talk about a "no whining" policy. If you bet on CAB and PnP thinks it's a dead end - tough.

If PnP decides that Prism v.2 would be better if it broke Prism v.1 ... they should break v.1. Because their first responsibility is to the guidance, IMHO.

Of course communication is key. They shouldn't flit from flower to flower. That's why I called for a specific "Sell By" date and declared obsolescence.

I'm also urging PnP to be bring greater attention to other implementations of the patterns. Contrasting implementations enrich our understanding and are a vital component of PnP's educational mission.

Microsoft and PnP win whenever developers embrace effective programming practices whether those come from inside or outside Microsoft.

I suspect there is an opportunity to educate more effectively and find relief from unwanted long term maintenance.

David Nelson said...

I agree with your point about expectations. But frankly I think it is something that PnP has brought on themselves by not positioning themselves more explicitly as something other than a product group. DevDiv, and especially the .NET division, has established a very strong backwards compatibility policy that developers (for better or worse) have come to rely on. It is no surprise then that consumers of PnP projects expect the same thing. I agree that PnP should be able to break or drop a project whenever they feel it is appropriate. But I think they need to make that case very strongly up front (your expiration date idea is a step in the right direction).

They also need to downplay the importance of user-requested features. As developers we all want to please our users, but if these truly our guidance projects, then being feature-complete should not be at the top of the priority list. User requests can drive the direction of the pattern implementation, but they should focus on the big pieces of functionality; corner cases are (or should be) irrelevant in a guidance project. The moment they feel the need to address specific narrow gaps in functionality, they are creating a product, not guidance. And their consumers pick up on that distinction.

I also agree that they need to draw more attention to open source and other available implementations. This is especially true for Unity: I like it and I use it, but only because I happened to see it used in another project about the time I was looking into DI. In a world with so many quality open source DI implementations, there really is no reason for Unity to exist. PnP could just point to these and then refocus their efforts into other areas that don't have the same coverage.