Putting The Cart Where It Belongs
In this posting, I continue addressing issues in the recent blog posting by Grady Booch. As I noted in my previous posting, the debate up to this point has been about the suitability of the Unified Modeling Language (UML) as a medium for model driven development.
However, that is not really the question we should be debating.
Instead of asking whether or not we should use our existing hammer (i.e., UML) to hit everything in sight, even things that don't look like nails, we should be asking what it is that we want to accomplish (i.e., model driven development), and what it looks like when done properly. Only after those questions have been answered is it appropriate to ask what languages, techniques, tools or other resources we should use.
Why? Because we cannot evaluate the suitability of UML or any other technology apart from understanding what we hope to gain by using it and how we will use it to realize those gains. To make this point more bluntly, requirements should drive technology decisions, not the opposite.
While this should be patently obvious, the debate about UML vs. DSLs continues to put the cart (i.e., modeling language technology) before the horse (i.e., requirements for model driven development). The debate should instead be about the methodologies that are proposing to use these modeling language technologies for model driven development, since they are both key sources and key repositories of those requirements.
This connection between methodology and modeling language technology is no accident. There is a finite set of practices for which every technology is well suited. Conversely, no technology is well suited to all possible practices. If this debate is going to address the practical concerns of those who will use modeling languages to develop, test, deploy, operate and maintain software systems, it must therefore be broader than a debate about whether to use UML or domain specific languages (DSLs).
I am therefore refocusing the debate, or at least the part of it that weaves through my blog, to the issue of Software Factories vs. Model Driven Architecture.
Grady took up this focus in his posting with his comments on Software Factories before turning to the discussion of UML. Despite the inaccuracies in his characterization of Software Factories, which I answer below, I see his decision to bring methodology into the debate as an important step in the right direction. It was an acknowledgement that UML does not stand alone as a modeling language, but comes wrapped in an approach known as Object Oriented Analysis and Design (OOA&D).
Indeed, as noted in my previous posting, the UML is a direct outgrowth of OOA&D, and is used primarily to support the practice of OOA&D, despite its apparent aspirations to parlay its undisputed success in that arena into a new career as the lingua franca for model driven development.
Grady does a good job of explaining that software factories are *not* at all about stamping out endless copies of the same thing, as some have mistakenly claimed, but rather about automating rote and menial tasks, so that developers can get on with the abstract reasoning that humans do so much more effectively than tools.
That said, he also makes some misstatements about software factories. For example, he quotes Tom Demarco’s writing about early experiments with software factories twenty years ago in Japan, asserting that software is a development activity, not a production activity, and that trying to make it a production activity produces bad software. With due respect for both Grady and Tom, whose collective works I greatly admire, I offer the following points in contradiction to Tom's initial assertion and to Grady's invocation of it.
· First, production activities can yield good software, as well as bad software. Why? Because software quality is not a function of production. Production in any industry is about copying masters. Apart from gross mistakes or media errors, copying software does not affect its quality. Copying a good master produces good replicas and copying a bad master produces bad replicas. The quality of software is therefore determined almost entirely by its design and implementation.
· Second, I find it surprising when people assert that production has no place in the software industry. It seems to me that producing CDs, DVDs, downloads and other copies from masters is actually quite essential to the survival of the software industry. We certainly care deeply about production here at Microsoft. From this observation, I conclude that software is both a development activity and a production activity.
· Third, as should be clear by now, production is a red herring in this debate. The development process by which the masters are produced is the real concern. Indeed, in many situations, we might never produce any copies of a given master, or perhaps only a handful of copies.
· Fourth, those who have studied industrialization know that in addition to economies of scale in the production process, mature industries seek economies of scope in the development process, as explained in the Software Factories book, and in my articles on MSDN. Software factories, as we define them, are about economies of scope in the development process, not about economies of scale in the production process.
Instead of repeating the lesson on economies of scale and scope from the book here, I will simply point out that software factories are about reusing patterns, frameworks, tools, templates, requirements, tests, instrumentation, process guidance, and many other assets used throughout the software life cycle, in a systematic, rather than ad hoc fashion, not about stamping out endless copies of the same thing.
It is worth noting, as we do in the book, that this is not really new. We already reuse some assets systematically, such as operating systems, web servers, class libraries and user interface designers. The goal of software factories is to radically increase the amount of systematic reuse in software development, so that much more of the application architecture can be implemented in the same way that UIs are implemented with UI builders, and data access is implemented using SQL engines. We are also interested in making it easier to work at higher levels of abstraction than we can with general purpose languages. For an interesting apologetic on this topic, see the recent article by Sergey Dmitriev. I'll have more to say about what Sergey calls Language Oriented Programming in subsequent postings.
The first volley on the topic of Software Factories vs. Model Driven Architecture, which Paul Ballard brought to my attention, has already been fired by Wim Bast in a news posting on The Server Side .NET, which I have answered there.
Comments
- Anonymous
January 05, 2005
The comment has been removed - Anonymous
January 07, 2005
In addition to my previous entry, I'd like to comment on Jack Greenfield's view of UML and it's shortcomings in the field of Model-Driven-Development (MDD). Jack describes UML as a useful means of object oriented analysis and design here and...