Well, here I go again.  It seems I must be having fun!  And, I admit, I’m encouraged by the kind words I’ve received so far – for which, thank you.  But let’s hope this doesn’t turn into one of those ‘blog fast, dry young’ affairs.

Last post, I talked a lot about what a model can do for you.  But I think it’s also important to talk about the proper limits of a model, and what happens at the edges. 

I’m sure we’ve all had the experience of working with a product which gives access to its wonders through a model of its own invention, but does not really admit of any other world view.  We’re grateful for the value it delivers, but frustrated that we have to dance to an alien tune to add needed behavior that the product doesn’t cover.  Cozy support becomes stifling straitjacket.

This is why it is important in product design to pay very careful attention to what a product does not do.  This has two aspects: making the design center of the product very clear, so that its use in practice plays to its strengths; and working through a whole series of scenarios in which the product is only part of the solution, to make sure that it can be fitted neatly into a larger jigsaw puzzle.

We kept these considerations strongly in mind when we were designing the Windows Workflow Foundation.  The design center is simple – make developers more productive when building workflow-enabled applications. With the focus on productive development, we knew from the beginning that we wanted to offer a smooth transition to code wherever the model added no direct value.

Of course, finding the right balance and transition between model and code was never going to be easy – we tried out quite a few variations over the two years we were working on WWF.  We think we got pretty close in the end.  But now we’re in the hands of the final arbiters – yourselves – and I hope you'll tell us loud and clear how well we really did.

Another huge factor was that we weren’t building a standalone product, but a part of the Windows platform, the System.Workflow namespace in WinFX.

That meant very high standards for consistency with the rest of WinFX, approachability, conceptual clarity, naming, and intelligibility.  The WinFX guys (including Brad Abrams and Krzysztof Cwalina) did a great job helping us to get there.  I love the fact that I can show a complete, understandable and working Worfklow host on a single legible slide – less than 10 lines of C# in the Program.cs of a console app.  Just install the  WWF SDK and create a Sequential Workflow Console Application project or a State Machine Console Application project, and you’ll see.

But perhaps the greater challenge was that the target scenarios are unbounded.  When building a platform, it is a major mistake to imagine that you know everything that you are going to be used for.  In fact, a key success criterion for us is that you, the developer, should be able to use our framework to build things we have never even imagined.

This meant that any model we came up with could never be definitive.  We could (and did) make it as useful as possible – without core commonality there could never be a viable ecosystem - but we always knew that we needed an open model that you could extend and shape to your own purposes.

The Windows Workflow Foundation model is open in many ways.  We provide Sequential Flow and State Machine workflows – but you can invent a completely different style of your own, if you wish.  We provide a notion of Sequence within a Workflow – but if you’d prefer one that executes its children in random order, go ahead, that’s fine.  You can build new workflow elements (i.e. Activities) out of old, either by deriving from them or composing them, much as you can build custom controls for a form.  Or you can just go ahead and code some completely new workflow element from scratch.  All the APIs used by the workflow elements that we ship are public and documented.

Our core aim can be summed up simply – deliver value, then get out of the way.  So, there are two things we would like feedback on.  Firstly, did we deliver the right support, are there important, common things that we missed out?  Secondly and perhaps more importantly, did we succeed in getting out of the way, are there times you have to wriggle around us?

You can give us your feedback here.  Be sure we will be listening closely.