I wonder therefore why Microsoft has taken the Factory Factory Factory Factory approach in making its own Factory.
He notes that we're only building one product and therefore wonders if we're a good factory candidate. The pragmatic answer is - because it's quicker.
I think this comes down to where you draw your boundaries and how you think about a supply chain. We see our own Dsl Designer as part of the same line of products as all of the designers built by all of our customers. Of course, if we weren't building designer designers for our customers then we probably wouldn't build a designer designer designer to design our own single designer designer!
(If this is too many designers in one sentence for you then welcome to my world.)
As I've said before this doesn't mean we get to model and generate all of our tool, but it gets us drastically better productivity on about 70% and lets us focus our coding attention on new stuff that's specific to our sub-domain.
You might think of designers for designers as a narrower domain on top of the broadly horizontal domain of visual software designers, which itself sits on top of the very broad domain of IDEs (or IDE plug-ins). I think we can probably all agree that productivity goes up as you get narrower.
Martijn suggests that broad variability means that enterprise apps isn't a promising place for DSM - I agree that it's probably not a world-changing end-point, but as a mid-point to be further specialized into verticals by customers and partners it seems like exactly where platform companies have typically played as an enabler.
Of course that does mean we'll have to make the whole extensibility thing for factories very straightforward in order to allow that kind of supply chain to build up.
That should keep us busy for a little while.