BTW, if you haven’t seen Steve’s entry on Isomorphism, go read it right now. He nails this whole services as contracts vs. services as code debate right on the head. The spot on nature of this post reminds me when he nailed the modeling problem on the head – another must read post if you haven’t already.

Last week, I had a great discussion with the Product Unit Manager (or PUM) of VSTA. She wanted my perspective on a few things related to Software Factories and I figured I’d share some of them here.

First off, while I appreciate the vision of factories, I’m also focused on the short term gains of automating software construction. Today, most of that automation is in terms of code generation. For example, John asked the other day if I thought Yacc is a software factory. It certainly is a domain specific language! However, I’m not sure I’d go so far as to say it’s a factory. But on the other hand, I’m not sure it matters that much if it’s a factory or not. When the other John on my team blogged his thoughts on SOA, he included one I wrote: “Eventually we’ll stop talking about SOA and go back to talking about Architecture”. I feel sort of the same way about factories. As long as we’re talking about it as if it is something different from what we’re already doing, we’re not there yet. But if we keep taking steps in the right direction, eventually we’ll get to the point where the process of building software doesn’t look the way it does today. Sorta the same way that building software today doesn’t look like it did pre-.NET, pre-VB, pre-Windows or pre-C++ (I could keep going, but I think you get the point). That’s the thing about visions, you never really get there, it just provides a way to keep you going in the right direction.

Secondly, I think that one aspect of Software Factories that at least I haven’t focused on is reusable frameworks. The book is called “Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools” but I think the focus has been mostly on models and tools. This is partially because of the whole DSL vs. UML flack (quick side note – how about we have both?) and partially because the DSL toolkit is the first factory-esque thing that we’re shipping. However, DSLs big value, IMO, is to automate the construction of applications built on top of well designed reusable frameworks. For example, the OOPSLA keynote demo was a DSL that would sit on top of a UI process framework such as the p&p UIP block. But if there is not a good framework, there’s little point in having a language. I’ve pointed out in the past that the big gap to cross for organizations to start using DSLs is the leap from building abstractions to building languages that automate that abstractions. However, that’s not really true. The really big gap is the leap from building one-off abstractions to building reusable frameworks of abstractions. Once you have the reusable framework, building the DSL is an easier step IMO.

Even though I didn’t figure out the framework / factory connection until last week, it must have been there in the back of my mind when I was working on the ARC track for TechEd. We’re having a session on “Design Considerations for Enterprise Application Frameworks” with Steve Maine as the speaker.