Back in November, we published a series of articles about Software Factories. As excited as I am by the concept, Chris Sells really brought me back to earth with this post:

I’ve been reading each of the Software Factories articles with great interest. Part 1 and part 2 did a particularly good job describing the elements of the problem space, I thought. However, when I get to part 3, I was ready to see a solution. Instead what I got was a long abstract piece defining the bits of what makes up a software factory. This is the kind of thing I’d be ready to read after I was shown a concrete example or two of working, running software factories. Do other people like reading these long, abstract articles? I find them tedious unless they’re filling in and generalizing the details of something that I’ve already got a handle on.
[Chris Sells – Concrete Examples of Software Factories?!? – Nov 7th, 2004]

When we were planning the ARC track for TechEd this year, I sent this post to Keith and Jack and told them I wanted to show a concrete example of a working, running software factory. I wanted to impress Chris. Today was ARC302 – Building and Using a Software Factory with Jack and Wojtek. I don’t think Chris was here today, but if he had been, I think he would have been impressed. It’s one thing to see all the various parts working on their own, but it’s very different to see everything working together in concert.

The factory scenario they demoed was for building smart client apps. p&p already has a bunch of existing assets like EntLib and UIP that is useful for building smart clients as well as a ton of guidance for building smart client apps. But long books and source code projects are not the easiest form of guidance for developers to consume. The factory ties these assets and guidance together to provide a powerful in-tool experience for building such applications. For example, they started by instancing a smart client solution template. This had two projects – the UIP related code and the main application code. The UIP project had all the boilerplate code that every UIP project needs to use, but it didn’t have any code for individual UIP page flows. So they invoked a GAT recipe to create a UIP page flow. This is one way where factories differ from traditional wizards – wizards are typically only invoked when creating a new solution. Factory recopies are invoked after the initial wizard runs, meaning you can unfold the template incrementally as you go along. So in this case, you invoke the recipe to create a UIP page flow multiple times, once per flow you want to create. Running the recipe created a bunch of files, but of primary note was a DSL model file and two code generation templates. The model file was for a cool little DSL for laying out UIP page flows. The code gen templates generated all the code for the forms and the flow control as well as the config needed to implement the page flow as designed in the DSL. Then they wired up the generated forms to a web service, including usign a service agent to cache web service call results on the client.

All in all, it was a very full featured app to build in a very very short amount of time. What was interesting is that there was very little hand waving when it came to adding code. You know how demos go where they add literally pages of code? In this demo, they’d swap out the file with the empty method for one where the method had like ten lines of code. And on top of being full featured, it followed the best practices design put forth by out patterns & practices group. So it didn’t fit the mold of a “quick & dirty” demo – how often does a demo app that you build on stage conform to best practices?

I gotta get through the end of this week, but then I want to get a video of the demo up on the web so you can see what I’m talking about, even if you didn’t go to TechEd or attend the session. I’d love to get the code too – it’s all running on VS05 Beta 2 – but you know product group guys…the next version of the demo is going to be even cooler…I think I can convince Jack to ship the current code and then ship the even cooler demo code when they get that finished.

The May CTP of the DSL Toolkit is finally here, as per Jochen's blog. The big new feature is compatibility with VS05 Beta 2, but according to Jochen this CTP also includes:

• New features for the model explorer and property browser in the generated designers.
• New shape type with collapsible compartments like in the Visual Studio Class Designer.
• New text templating (code generation) engine with richer features like an include directive.

They haven't updated the DSL Workbench pages yet, but you get the CTP directly from the Download Center. You can also leave feedback in the MSDN Product Feedback Center.

I’m not sounding off in the pub, so I guess I’ll blog the workshop that Alan and Steven Kelly from MetaCase are doing at XP2005. It’s called “Agile Development with Domain Specific Languages” and here’s the abstract:

This workshop will investigate the application of Domain Specific Languages within Agile development. A Domain Specific Language (DSL) is designed to express the requirements and solutions of a particular business or architectural domain. SQL, GUI designers, workflow languages and regular expressions are familiar examples. In recent years, Domain-Specific Modeling has yielded spectacular productivity improvements in domains such as telephony and embedded systems. By creating graphical or textual languages specific to the needs of an individual project or product line within one company, DSM offers maximum agility. With current tools, creating a language and related tool support is fast enough to make DSM a realistic possibility for projects of all sizes.

I’m still digging out my inbox after my two week vacation. I’m down to 134 items from nearly 400 this morning. I was at 16 before I left. If it gets this bad in two weeks, what’s going to happen when I take my four week paternity leave?

While I’m getting up to date on email, I am way way way behind on blog reading. But I did see that Gareth is promoting a web chat about the DSL toolkit tomorrow at 9am Pacific time. Here’s the abstract:

Using the Domain-Specific Languages Tools for Visual Studio 2005

Domain-specific language tools lay the foundation for software factories by providing a framework and a set of tools for delivering domain-specific visual designers that plug into Visual Studio Team System. These designers could be tools for industry verticals, such as the health care or telecommunications industries or, they could be tools for development across numerous disciplines, such as object-oriented modeling and architecture. The Microsoft Tools for Domain-Specific Languages is part of the Visual Studio 2005 SDK.

Now if we could just get a copy of the DSL toolkit that runs on Beta 2!

FYI, I’m presenting at the monthly meeting of the International Association of Software Architects Puget Sound chapter Wed night (4/27). I’ll be talking about DSLs and Software Factories, including a hands-on look at the tool. If you’re in the Redmond area, the meeting is on the Microsoft campus in Building 43, Room 1560 – the Jefferson Room.