This article is more than 1 year old
Microsoft’s software factories
We talk to Jack Greenfield about the future of Visual Studio
At Microsoft’s Architect Insight conference in Wales this month, Microsoft software architect Jack Greenfield tells us about a BMW factory which rarely makes the same car twice. It is an example of mass customization, handling millions of variations within an automated process. Could the same apply to software development?
“I know that software is not exactly like anything else, but we flatter ourselves if we think it is radically different,” he says. The challenge of software development is in meeting unique user requirements with general-purpose platforms and tools. “We ought to be able to produce a wide range of variants from a pre-defined set of parts, plans, and components, largely by assembly but also with some customization.”
This is the essence of software factories, which Greenfield defines as “reusable assets that support the enactment of custom processes.” In the context of Microsoft’s platform, this means a Visual Studio add-on, supported by templates, libraries, tools, wizards, models, patterns and guidance documentation. He believes that between 40 per cent and 80 per cent of development effort can be automated.
Is this just another bunch of tools and wizards for Visual Studio? Not really. Greenfield insists that his team is building a platform, rather than merely supplying tools. It turns out that this has been a matter of internal debate: "Rick LaPlante, who did Visual Studio Team Suite, got funding to do modelling," he told me.
"The charter for the group was to build tools for web service design. Some of the folks involved had an interest in how logical designs of the architectures of systems map onto the logical designs of the infrastructure to which they will be deployed. Hence the tools in Team System, which were about design for deployment. There are really four designers, and in our parlance we’d say they are four viewpoints, four aspects of the problem being modelled.” This was the project code-named White Horse.
At the same time, the team “had a much broader and longer vision than was being realised in the group”, according to Greenfield, and wished to move beyond the confines of the charter. Rather than supply just four viewpoints, the team wanted to make it into a tool for creating viewpoints. “We said, inside those white horse tools which have been built as a monolith there are some frameworks hiding.
We’d like to harvest them out and wrap them with authoring tools so that third parties can build their own designers.” This is what became the Domain-specific Language (DSL) Tools, released as part of the Visual Studio SDK. At that point, there was a management change, and the team reverted to focusing only on the original White Horse tools; everything else was on ice.
Greenfield expresses frustration with the “White Horse” tools as shipped. ”It was discovered that architects use those tools maybe a couple of weeks a year. They are not extensible. They describe a few interesting viewpoints in certain kinds of systems, but it wasn’t the platform that people needed, which they could customize.” The outcome was that Greenfield's team got together with the team responsible for “Patterns and Practices”, architectural guidance for software development, and returned to the broader platform vision.