I typically ignore the Microsoft marketing machine: while occassionally entertaining, the messages therein are typically so void of detail, suspect of schedule, and full of noisy FUD that they are distracting. Recently, however, a colleague forwarded me a link to a presentation about Visual Studio 2005 Team System that I couldn't ignore, because of its use of phrases I remember writing several years ago.
I do respect Microsoft's work in this space: development is a team sport, and tooling for most domains requires far more than just a faster/better/cheaper compiler and debugger. In the VSTS Tech Ed 2004 presentation cited, Rick LePlante and crew presented Team Studio. What first struck me is his use of the phrase "friction free" development. About four years ago, Alan Brown and I wrote a paper on collaborative development environments (since published in Advances in Computers, volume 59 and also mentioned in my EclipseCon keynote provided in the references section of the blog). Rick is correct - though he's a few years late in recognizing it - in that integrated development tools are all about reducing the friction among different stakeholders. Speaking of stakeholders, the Microsoft presention here is also virtually the same as IBM Rational has described for several years with regard to our suites, and their mention of having a rich partner ecosystem is what Eclipse is all about, although the former is captive and proprietary while the latter is open.
Following the demo in Rick's presentation was interesting, but IMHO a bit naive: on the one hand, Team Studio does automate some of the mechanics of change control (that's a good thing) but it totally ignores the things that can be done to address the social dynamics of collaboration (that's a bad thing). Some of the things Team Studio automates simply adds some ceremony to what you'd get in a development team that was already jelled and embodied good communication patterns, but the scenarios covered by Team Studio didn't necessarily encourage those good practices in teams that were geographically and/or temporally distributed or already somewhat dysfunctional. Messaging, presence, the formation of small, temporary work groups, lightweight artifact workproduct versioning, the existence of a virtual team meeting space: these are collectively critical to addressing those social dynamics, and that's the trajectory that I see such tooling needing to go (also as I explained in the EclipseCon keynote).[Read More]
Software architecture, software engineering, and Renaissance Jazz
gbooch 120000P81R 443 Visits
gbooch 120000P81R 413 Visits
I've been slogging through a 3 foot high pile of clippings and articles I've collected the past several months, all randomly encountered factoids on various of the systems under study for the Handbook.
Politicians have think tanks, but check out Vanguard, one such group for our industry.
On a completely unrelated topic (I told you these were randomly encountered; this is sort of a meta-archeological dig I'm conducting), while most of you reading this are likely engaged in enterprise systems, there's a whole world out there beyond servers and such, as for example in the area of medical electronics. I've met some teams who build such devices (thank you!) and recently encountered a computed tomography system from Siemens. The physics for these devices are well-understood, and while there continue to be hardware advances in terms of resolution and performanance, the biggest focus in this space is the operational software; labs typically buy a machine (a million or so a pop) but then enter into a stream of software upgrades over the years, adding various features and improving visualization. I honestly know nothing about the software architecture of such devices - which is why it's in my list for the Handbook (I write books in order to learn, and there's soooo much that I don't know).[Read More]
The past couple of months, Microsoft has unleashed a torrent of words detailing their marketecture for software factories. Alan Brown and Simon Johnston of IBM Rational have previously and very ably commented on this work, but Steve Cook of Microsoft has drawn me into the fray in his blog, so I feel compelled to reply: Steve wrote "I hope Grady Booch reads this"; well, I did :-).
I know many of the folks involved in Microsoft's software factory effort, and I very much respect what they are trying to do. We have differences of opinion, as you'll see in this blog, but it's good to watch Microsoft putting some energy into improving the development experience. As I've said many times here and elsewhere, software development has been, is, and will remain fundamentally hard, and whatever can be done to improve the profession of developing software is a Good Thing.
That being said, I'm disappointed that Microsoft choose the term "software factory," because it's an emotionally-laden phrase that harkens to extremely mature manufacturing methods that focus on stamping out endless copies of the same thing, although perhaps with slight variants therein. There's no doubt that reuse at the level of design patterns or, even better, vertically-oriented architectural patterns is a Good Thing, but what Microsoft is proposing to do is not exactly like the manufacturing metaphor, and so their use of the term is a bit misleading (although Steve has curiously used the image of a conveyor belt when describing the Microsoft factory process). Tom Demarco in his book Why Does Software Cost So Much? sets aside a chapter on software factories in which he notes - and I agree with him - that "I think factory methods for software are dead wrong, witless, and counter-effective. Organizations that build good software know that software is an R&D activity, not a production activity. Organizations that try to make it into a production activity produce bad software (though potentially lots of it)."
At OOPSLA, Rick Rishad of Microsoft publically spoke of their strategy (in a somewhat controversial way, as reported by Spencer F. Katt, which was a bit surprising given the typically-frictionless Microsoft marketing machine). That strategy was subsequently reviewed in ADT Magazine. While I agree with much of that article, they too fell into the pit of taking the software factory term a bit too literally. Perhaps the best source of Microsoft's deep thinking in this space, in addition to their site, is the book by Jack Greenfield and others, titled Software Factories: Assembling Applications with Patterns, Models, and Tools. Therein you'll see Microsoft's emphasis upon resuable assets and tooling to support them.
To that end, there's considerable common ground between IBM and Microsoft's approaches to the problem: we both agree that resuable components, as manifest both in code as well as in patterns, are the right next stage in cutting the Gordian knot of software. Indeed, IBM's been in the pattern space for sometime, starting with many of the authors of the seminal book Design Patterns to the current work led by Grant Larsen and as manifest in the open standard we pioneered through the Object Management Group, the Reusable Asset Specification.
However, we do disagree with Microsoft's rejection of the UML in favor of proprietary domain-specific languages, as noted not only in Jack's book but also in Alan Will's blog. To be clear, as Jim Rumbaugh has commented back to me, our observation - and that of our customers - is that the UML has proven itself useful much of the time, yet there are a few purposes for which it may be less appropriate. In many cases, the semantics of the UML are pretty close to what you need, although they are deeper than necessary; in such cases, a suitable UML profile is sufficient to focus the language, which allows you to leverage standard UML tools and training and yet eliminate the bloat. In those cases where the business concepts are more naturally expressed in a specialized syntax, then inventing a suitable DSL is reasonable. At the extreme, this is essentially the path that Charles Simonyi has been trodding for some years, a path that requires a very very deep and integrated underlying semantic model. Indeed, as I've pointed out in one of my earlier blogs, the root problem is not simply making one set of stakeholders more expressive, but rather weaving their work into that of all the other stakeholders. This requires common semantics for common tooling and training, so even if you start with a set of pure DSLs, you'll most often end up covering the same semantic ground as the UML.
Will's blog had a number of errors of fact, which Bran Selic has pointed out to me and so which I'll paraphrase here. Alan wrote "So here's why we don't want to limit ourselves to the UML as a basis for our users' domain-specific language" and then went on to say:
"A careful look at the specialization mechanisms for UML reveals their limitations. Stereotypes and tagged values allow you to change icons etc, although even simple alterations like decorating a box to show the state of some property isn't within range. You can't change the semantic constraints, or invent new sorts of diagram or new categories of element." This is incorrect: a stereotype allows you to define a set of associated constraints (in OCL, for example) that can capture the characteristics of your domain-specific context. While it is true that you cannot violate the semantics of the metaclass that you have stereotyped, this is actually an advantage of the stereotypeing mechanism. A stereotype is a type-compatible specialization of an existing UML concept. Consequently, you can reuse standard UML tools and expertise even though you are using a domain-specific language. Of course, if you want a language that is incompatible with UML, that is OK as well (specifically, you can define it using MOF), but you will be losing some of those benefits.
"You can't take stuff away, so your users are always distracted by other options and elements and diagrams that aren't relevant to your language. Tools that use a UML editor as a front-end have to have a (very annoying) validation step before they generate their DB schema or whatever it is." Also incorrect: as Jim noted above, a UML profile can remove any metaclasses it chooses.
"UML only includes certain types of graphical format. If you want your language to include tree-structured diagrams, or tables, or math formulae, or block-structured text, or prose, or if you want hyperlinks - well, I think you'd have a hard time. While our initial offering won't include all those styles, we'd certainly like to support them at some stage in the future." Actually, the current UML spec really does not restrict graphical formats in any way -- it simply provides a standard set of notations, but not at the exclusion of other notations. In other words, there really is no "illegal" UML graphical syntax. The formal definition of a UML graphical syntax is an outstanding item before the OMG. While this is not good, it also means that Alan's criticisms about its graphical restrictions are misguided - and Microsoft too acknowledges that these different graphical representations are a future desire for them, not a present reality.
"An important aspect of the definition of a modern language includes how you interact with it: how you navigate and elide or elaborate and edit etc - think of your favorite GUI composing tool, in which the GUI-defining language is scarcely separable from its editor. You can't do anything about these aspects in UML." We agree - but this has nothing to do with the UML but rather is all about the tool environment. IBM's tooling approach is to build upon the open standard of Eclipse, not a proprietary IDE.
"What you get out the back of one of our tools says things like CheckinDesk and ConveyorBelt. What you get out the back of a UML tool says things like Class and Stereotype - much more difficult to read. (Yes, of course you could write translators, but it's an extra layer of hassle.)" This is also incorrect: using the UML, at the model level you get back stereotypes called CheckinDesk and ConveyorBelt. At any rate, why would anyone want to look at things at the XMI or metamodel level? XML is not really for human consumption, and ultimately, MDD is all about raising the level of abstraction for the developer.
"You have to understand all of UML (stereotypes etc) before you can create your language on top of it." Not true: you just need to know the subset that you are specializing (mostly it has to do with things such as classes and associations which is what most profiles specialize). Of course, if you want to specialize state machines, you need to know the metamodel. But, if you don't care about state machines, you can ignore them safely.
"Your users have to understand an editor that's intended for something far more complex than they probably have in hand - or at least whose complexities are in a different direction." Again, this is a issue that confuses tooling with language definition.
I hope that Steve and Alan read this :-)[Read More]