Steven Kelly on DSM

Microsoft Consulting Services manager Guy Ron(*), quoted by Ron Osherove at TechEd, says that the Software Factories initiative will "most likely fail". (About as good a marketing message as their lead product manager admitting that using their tools requires "a massive amount of effort"!) The rather weak evidence Guy bases this claim on is that Microsoft's HL7 software factory has still not been finished. Whilst failing at something on your first attempt hardly says you're never going to succeed, Guy and Roy do make some good points. So does Mauro Regio, who was the initiator and architect on the HL7 project, in a comment on Roy's blog. I'd summarize the valid points as:

• Massive projects with many stakeholders cannot agree on one set of concepts
• Domains should be "real world", i.e. problem domain, not implementation domain
• The more specific the domain the better
• Microsoft don't yet have the tools to make this work - but GAT and the DSL tools are headed in the right direction.

Let's be realistic: this was Microsoft's first attempt, and as far as I know not a single one of the people had experience in DSM. Only when you're experienced at something can you reduce the apparent complexity without sacrificing important details. When you try without that experience, you miss important stuff out in some areas, and in others leave or even add more complexity and flexibility than are necessary. We did that building the first version of MetaEdit back around 1990, and probably also in the first DSM languages we built. It's no great shock to see similar errors being made by Microsoft or Eclipse: since when did our industry ever learn from previous mistakes?

It also seems a little unfair to criticize the whole Software Factories initiative because they couldn't achieve much in a year with the current Microsoft toolset. Others have had similar problems: Edward got up to #20 in his series on a tiny language he was trying to build for over half a year, before apparently giving up: nothing for over two months :-(. It seems only individuals and massive industries have the money to burn on trying to do a project using pre-beta software, and of a version 1.0 to boot. Whilst the adage claims only a bad craftsman would blame his tools, surely a good craftsman can recognise whether a tool is effective or not?

For DSM to work optimally, you need a good toolset, a good knowledge of what makes for a good modeling language, and the abstract thinking skills of plucking a coherent domain out of the tangle that is the real world and whatever applications you already have. Our experience is that it's best if these attributes come together in someone who is an expert developer in that domain. It's easier for them to learn our tool, than for us to learn their domain.

Things can also work if we have the extra skill of eliciting the domain from them, and that's something that has improved with practice. Whilst it makes it easier for people to get started -- we can offer a "solution" or "service" rather than a product -- it is harder to ensure that the resulting language will evolve with the domain.

It's a bit like outsourcing: sure it's tempting to hear that somebody else can do it for you, but are they going to be around to fix it or improve it later. And with DSM, the domain is invariably the core competency of the organization -- and who in their right might would outsource their core competency?