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.