I was fortunate to participate in several MSDN podcasts on the subject of model-driven development with such industry luminaries as Jack Greenfield, Steven Kelly, Mauro Regio and Brian Selic. I was the voice of the average joe schmo developer trying to make sense out of all the amazing things these other panelists had to say. It was both fun and a bit intimidating at the same time. It was also quite popular with the listening audience - these podcasts received thousands of downloads.

Well I just noticed that the podcasts have been transcribed, and the transcriptions are available on MSDN here:

Model-Driven Development (Part 1)
Model-Driven Development (Part 2)

Although the transcription is a bit mangled in some places, they generally did a good job of capturing what was said. Of course, you can always listen to the original podcasts:

ARCast 5: Model-Driven Development
ARCast 6: Model-Driven Development

At first I didn't like the Microsoft Solution Framework (MSF). All I had to go on was the MSF process guidance and whatever was floating around in blogs and forums. It all seemed rather obscure and vague. However, as I work with the process template I'm starting to develop a new appreciation for it. Although the process guidance has plenty of room for improvement, and the MSF CMMI template is overkill for most situations, the work items and reports in the MSF Agile template are actually quite useable.

I was poking around the blogosphere when I came across a series of posts from Clara Oscura. She has done a fine job of clarifying the terms and concepts used in MSF. I hope her work makes it into the MSF process guidance.

MSF: Tracks, workstreams, activities, areas and iterations
MSF: Tracks, workstreams, activities, areas and iterations (II)
MSF: Tracks, workstreams, activities, areas and iterations (III)

Thanks for the nice work Clara!

An important component of a software factory is guidance. After all, a software factory is a highly specialized IDE for product a specific type of software. Without some instructions on the proper use of this highly specialized IDE the developer is pretty much lost, left to bump around in the maze until a sense of direction is established. Good guidance eliminates this disorientation, allowing the software engineer to use the factory productively right away.

An excellent source of information on engineering good guidance can be found at:
http://channel9.msdn.com/wiki/default.aspx/GuidanceEngineering.HomePage

Hey, I guess this guidance engineering wiki could be called meta-guidance!

J.D. Meier reports on his blog that the Microsoft Patterns and Practices team has just released new prescriptive guidance for Visual Studio Team System. This is a CodePlex project that contains a wealth of guidance on best practices around Team System. It looks like they are focusing on source control first, but I'm sure that additional guidance will be added in the future related to test and build.

This morning I was reading Scott Ambler's excellent article on Single Source Information, which references Brad Appleton's Locality of Reference Documentation (LoRD) article. In a nutshell LoRD states that:

The likelihood of keeping all or part of a software artifact consistent with any corresponding text that describes it, is inversely proportional to the square of the cognitive distance between them.

In other words, if the code is over here and the documentation is over there then the likelihood of keeping them in sync is low. For this reason its best to keep the documentation close to the code. Ideally, the documentation should be in the source code file. This is why both Java and .NET support inline XML documentation comments in source code files. Javadoc and NDoc are both utilities that format these XML documentation comments into help files. Since these XML comments are embedded in the source code file, right next to the classes, methods, properties and events that they describe, the cognitive distance is zero. When a developer changes any of these items, the documentation comments are right there - in the very same spot - ready to be updated as well. It just doesn't get much easier.

Shortly after re-reading these articles, and while the thoughts were still swirling around in my mind, I stumbled across the next generation documentation tool: Sandcastle. According to the overview on the download page:

Wow! Now this sounds like a really useful utility that makes the cognitive distance between code and documentation as close to zero as possible. The beauty of this utility is that it automatically documents the structure of the code, and it also documents intent to the extent that names are descriptives. Now, if your dev team does a good job of keeping the the XML comments in the source code relevant, than this utility automatically documents both structure and intent in a clear and concise manner, while keeping the cognitive distance at zero.

Taking the whole thing one step further, Mike Diehl blogs on how to incorporate Sandcastle into an MSBUILD process. Once you have this up and running, keeping documentation current and relevant just doesn't get any easier!

Software development is a difficult endeavor. Development teams are expected to produce ever more complex software systems, yet economic forces require them to do it faster, better and cheaper. As software developers we have an unprecedented array of amazing tools at our disposal for developing, building and testing and deploying our software applications. We’ve made enormous strides in our methods with agile practices like iterative incremental development and test driven development. And yet we continue to build software applications the same way that automobiles used to be built - hand crafted one by one.

Let’s compare software development to the production of automobiles. Today a few very special automobiles are still built by hand. But if we had continued to build all automobiles in this way, then they would be enormously expensive and in very short supply. Quality would be erratic, safety and reliability would be problematic, performance would be unpredictable and parts would be hard to come by.  Thanks to the industrialization of the automobile industry, we have an amazing variety of safe, reliable automobiles that address a wide array of needs at a reasonable cost.

Since industrialization was so phenomenally successful for automobile production, can the same approach be applied to software? Can we industrialize the software development? In short the answer is yes! But what does industrialization mean in this context? Clearly software is not the same thing as automobiles. But is it really that different?

Every automobile has many features in common. Each automobile has an engine, transmission, brakes, headlights, a steering wheel, etc. Some features are required – like wheels, while other features are optional – like a GPS navigation system. Some features offer choices – like the color of the body, while other features offer no choice – such as the gas pedal.

When automobiles were first mass produced, each automobile was identical. Today when you order a car you have many choices – type of engine, type of interior, type of wheels, as well as options such as a sun roof, compact disc player and anti-theft security system. These choices are made possible through a technique called flexible manufacturing. Although each car coming down the production line is the same make and model, each one is also a unique. Each car is configured with a different set of features based on the needs and preferences of the customer. Through flexible manufacturing, the production line is capable of producing many variations of the same automobile without the need for retooling.

A software factory applies the same concept of flexible manufacturing to software development.  A software factory is a development environment configured to produce a specific type of application quickly and efficiently. The factory provides the tooling and guidance to rapidly develop a family of applications.

Each software application belongs to a class of applications; e.g., accounting system, word processor, ecommerce web site, etc. Within that class there are common features and variable features, in the same way that automobiles have required features and optional features.

The software factory combines a core set of common features with variable features that you select and configure. Once you have your custom feature set specified you use the software factory to automatically generate an implementation. You then manually tailor the implementation as needed to produce the finished product. In this way the software factory is a flexible manufacturing environment for software.

A software factory allows you to build software through mass customization, the ability to produce a range of similar applications by simply selecting the feature set for each application from a pre-defined set of features. This approach leads to economy of scope, where you achieve a significant increase in efficiency by leveraging reusable assets to build a variety of similar products.

In an earlier post I promised to make the MSF Analysis Tool available for download.

You can now download it at GotDotNet.

Go there, try it out and let me know what you think. Or better yet, improve the tool and share your enhancements at project workspace on GotDotNet.

You can get a sneak peak at the read me file here:

Read Me - MSF Analysis Tool.doc (34.5 KB)

The first-ever Boise Code Camp was a huge success! It was an all-volunteer effort based on the Code Camp Manifesto. There were 35 presentations on a variety of topics, and the 138 attendees gave it a big thumbs up. I thoroughly enjoyed the event, both as an attendee and a presenter.

As the lead for the methodology track I had the honor and privilege of moderating a panel discussion that explored methodology from several angles: people, environment and tools. The panel members were (from left to right) Dan Ray (Healthwise), Doug Seven (Microsoft), Kevin Call (Micron Technology), Jason Grundy (Treetop Tech), David Starr (Healthwise) and Jim McKeeth (Washington Group). These guys had a wealth of experience to share, and the audience came up with some great questions and observations as well.

I also gave a 90 minute presentation on Software Factories that included a demonstration of the DSL Tools as well as a demonstration of the Guidance Automation Toolkit. The presentation included a discussion of Software Product Lines and also covered the software factory process. Apparently the audience thought it went pretty well, giving the presentation an average rating of 8 out of 9.