In the final segment of the Sunday sessions, we had a “goldfish bowl.” Steven Kelly, Goren Olsen, Laurent Safa, and Arturo Sanchez each said a few words about “Evolution of DSM’s”. Then other participants could filter into the circle of chairs, ask questions and participate in the discussion, and then “fade out” when they were done.
Steve opened up with a point that (just like Tennessee in 1925!), people just don’t talk about Evolution in DSM. Everything assumes that you write this thing and then you’re done! This attitude is sufficient to get a working prototype for a research paper, but in the real world… clients may not tolerate this so much. He had a very interesting illustration of the interrelationships of the Model Language, the Models, the Generator, the Framework, and the Generated Code. How does a change in the model language cascade through a running system?
As the session topics and crowd response indicated during the day, most people in the room really wanted tools to help cope with evolutionary issues. They wanted to know how to deploy model modifications into an environment where previous iterations are still in operation. They wanted IDE tools to be seamless… they wanted IDE’s to understand the maintenance nightmare that DSM can unleash. They want things to just work– they want “flow through.” If the model changes, they want everything downstream of the model to be patched or rebuilt automatically. They want transformations to be automatically generated to handle all of this housecleaning. There seemed to be a consensus that UML just didn’t work– it’s too general. At the same time, there were hardly any presentations that didn’t have a completely incomprehensible UML diagram in their slides.
Steve would go into detail about what sort of things tend to break among the various competing tool sets. He noted that the XML-based tools are just too new as of yet to have any sort of robust answer to DSM evolution issues. The older tools have features for this because customers insisted on it. If they got put in a situation where their models suddenly stopped working, for some reason they just didn’t tend to respond well to the notion that they were going to have do all of the grunt work of fixing everything by hand….
Arturo disagreed with all of this. He pointed out that DSM’s should emphasize the “specific” part of the acronym. If you can handle all of this evolution stuff, what you’re developing is just another general purpose programming language! Steve didn’t appear to think that an attitude like this could last long in the presence of real paying clients. Also, he pointed out that if you can’t evolve, then you’ve pretty much lost the chance to ever reuse anything.
Steve spoke in specific terms about what sort of changes the current tools can tolerate. Most of them will let you add new properties. Some XML tools would make new properties “required”, though, which would cause the old models to break. Some tools could tolerate a renaming. Luis Pedro wondered why you couldn’t use new models and old models together– he’d used a database tool that could manage to produce the right SQL for querying something regardless of the actual version in operation. Steve didn’t seem to think that such tactics could work with DSM.
At some point, a Ruby coder jumped in and said that in the real world, you just don’t have time to mess with a bunch of pointless UML diagrams and fancy modeling. He urged everyone to work toward creating a system where you could make DSL’s so quickly that it would be easier to start over than it would be to “evolve”.
At the end of the discussion, Arturo reiterated his point that mixing evolution with DSM’s was crazy. (He had a real zinger– something like, DSM’s are revolution… and if you add evolution to them, you’ll get some serious retribution. Argh. I missed the last word, but it was something like that. Devolution? Contribution?) Steve said he was depressed. The current crop of tools are all inferior to the tool he was using 13 years ago! (Hint: Steve’s tools are built on Small Talk.) Luis Pedro reiterated the point that reusability required evolution.