IT Modernization < V. Hanniet

software model driven approaches

Successful MDA’s drawbacks… A true story #2

Facts

This (other) company, uses an MDA/MDD life-cycle since many years.It works fine but…

  1. A first problem, funny if you think of it, is that MDA works too well: developers who work on MDA projects for a while, say 3 years, lost part of their ability to be a “standard” developer. Say they develop in Java: as the framework plumbing is entirely solved by code generators, these developers are used to implement some business rules algorithms in Java. But they are not aware of the JEE framework around these algorithms. And as the GUI is mainly generated, these developers are neither used to develop client side code. By the way, this is also true for other situations. Say MDE R&D engineers: they learn a bunch of sharp technical strategies for optimizing data manipulation… But never meet JEE.
  2. A second problem is that the versionning is hard to manage: each application has to deal with 4 artifacts used to build it. This gang of four is: model, generator, framework, hand-added code. This is sustainable for one application alone, but becomes more touchy as soon as many applications share models and generators, and that evolutive maintenance comes around. As a matter of comparison, think of a more standard approach: model becomes textual specification, generator becomes architecture & coding rules. After their validation, and a first virtuous impulse, nobody take more care of these documents which are carefully stored on shelves in the hallway. We just keep undocumented, but living, framework and ad-hoc written code. More simple for sure.
  3. A MDA promise is that if the framework evolves we just have to adapt generators and generate the application again. Just to push a button, to launch automated NRT during the night, and when the morning comes out: hurrah, the appli now runs onto the new framework. OK. Say you really have 100% NRT automated tests. And a huge pack of applications weighing… Say 3 million line of codes. Well, you have to get the right versions of models, generators, hand-added code for each application (say there is only one framework version). Then to launch an error free generation. Then to launch the full NRT campaign. For sure it will take more than one night ;D

Comments

#1 – Told like that this could be a problem but… If this developer just came out school, fact is that he has been productive with a very short learning curve. And if he had the curiosity to look around his code, he probably has seen and learnt good design patterns. Probably much better patterns than what he would have produced if left in front a blank page, or even if left in front of pattern samples produced by the guy who left the school three months before him 😉 If this developer has experience in design… Why not give him modeling tasks, in addition to completing the code generated from these models? He could even give his thoughts on what he sees in the way the code is generated.

#2 – Configuration management is a big MDD drawback, the biggest I can see. Again, MDA leads us to work “well” and follow the rules. In real life, we generally don’t… For very good (and also wrong) reasons. Maybe a key is to be able to work on small parts in an agile way : I work on a story, I can get just the part of the model which is related to this story, just the code generators I need, just my hand-written code, and further more I can change myself the model, the generator (huh?), my code, the framework (huh huh?). Well, at least the team who build the generator and the team who support the framework should be next door. Inside the agile team… So easy to say!!

#3 – True problem. But anyway, if we absolutely need to use a new framework version on 50 applications we have a clear path to success! And if the path is a bit long… It is very shorter than without MDA!!

Featured image taken from http://www.cosmopolitan.com/celebrity/news/forbes-worst-stereotypes-about-successful-powerful-women

7 comments on “Successful MDA’s drawbacks… A true story #2

  1. meinte37
    14/10/2011

    My reply to the “accusations”:

    @1: I’d say that anyone who can _build_ MDE frameworks can brush up on the more industry-standard skill set in no time. As for the other developers who just develop using the MDE framework: (1) because of the Law of Leaky Abstractions you usually need to know quite a bit about the platform the MDE framework is targeting anyway, (2) most developers in the business seem to rely heavily on the combination of a small set of well-used and well-understood frameworks and something I like to call “heuristic pattern matching” which favors a copy-and-“this should work” approach over actual understanding over what’s going on. In short: the problem is there regardless of the use of MDE.

    @2: Re-use is a double edged sword and MDE does not escape this. As soon as you start re-using “stuff” across projects you’ll have a potential configuration management hell. MDA only makes it a little more complicated because of “meta dependencies”. On the other hand, different projects tend to target different (flavors of) platforms so you’ll have some customization per project anyway. I’m a staunch advocate of only re-using small modeling language kernels, composing these and building the actual modeling language from there. Building a generator is usually both the cheapest and the most agile thing in the project anyway, so I hardly see any reason to try and re-use generators across projects which target differing platforms anyway.

    @3: If such a migration is problem, then you haven’t been using true MDE. 3MLoC of hand-crafted code? Surely you should have taken the effort to pull large parts of that into the modeling language and model that. Same goes for automated tests: these should test behavior and are thus tied in to the models, which means the test suite can either be generated or should not directly depend on form of the generated code. Testing the generator can be done more efficiently by using a much smaller test model, diffing generator output with a reference implementation and running very specific “behavorial” tests against the generated application.

    • vhanniet
      19/10/2011

      Hi Meinte,

      @1: You’re right. the problem is there anyway through the “heuristic pattern matching” (I like your words!)

      @2: I agree on the re-use double effect. But reuse is a good decision when used appropriately. And model has to be considered as a primary artifact, not a meta one (generators are meta). So, configuration management is still a problem in MDA work-cycles.

      @3: In my sample the 3MLoC contain both generated and hand-written code. Anyway, tests generation is still a problem as soon as we don’t just speak of Unit Tests (more easy to generate… But much less value). And testing generators is not sufficient as you won’t test every modelling context.
      By the way, an alternative test approach for NRT in case of pure framework evolution is :
      i) compare a full “blank” generation (without hand-written code synchro) before and after framework changes, and be sure each kind of difference is well explained
      ii) add handwritten-code and be sure there is a place for each piece of hand-written code, and no empty room
      iii) if you have functionnal NRT, run them

  2. TY
    16/10/2011

    @vhanniet

    Talk about your second problem, the versioning or/and configuration management. I don’t know if it’s a big “drawback” or the biggest? but, of course it is a big big issue. 🙂

    I think there is more complicated background. There is a problem to the division of models: “model” is a countable noun, but how to define the boundary of *a* model? Is it nested and recursive? For the correspondence of divisions (units) between the layers such the models and the code, are they always some linear relations (mappings)? Is there a consistency of division between the different abstract layers?

    Furthermore, At a high abstract level, the versioning, configuration and change management may be not merely an IT problem, they may be often inseparable from the management and business affairs.

    These issues also relate to a basic proposition: is mechanical reductionism the appropriate organizing principle to software (including models)? Many familiar metaphors in software field such as modules, components, bus structures, and even code reuse, all have some shadow of reductionism. I think, in past software engineering, there is a tendency with reductionist worldview when analyzing the structure of a software system.

    • vhanniet
      19/10/2011

      Hi TY,
      I fully agree with you on this topic. Reductionism is a need for IT processes (just zeroes and ones!) but a big drawback if considering the real initial needs, explicit or implicit, explained or hidden.
      And a big drawback of forward MDE approaches is to bring into the game a reduction of the true needs, and to plug the solution building on top of it.
      That’s also one of my ideas behind the “lazy modeling” approach (http://vhanniet.com/2011/07/07/laziness-attitude/): at least, let us be aware that there are also important unwritten specifications ;D

      • TY
        21/10/2011

        I’ve read it, that is very practical, useful principles

  3. meinte37
    19/10/2011

    @2: I tend to regard generators less-and-less as ‘meta’ these days. I have too often tweaked -supposedly reused/reusable/generic- generators to some project-specific end in a way that would have been very uncomfortable to capture as a marking(s) model. With sufficiently advanced generator tech (Xtend2 comes to mind here), you can specialize/override/extend an existing generator without having to touch the original one. Then only the overrides are project-specific…all the more reason to regard them as not meta and constraint your configuration management hell a bit more.

    @3: Completely agree. Part of my point was that it’s good practice to do the things you’re describing against a controlled, small(ish) application/model first, before doing it for the actual application at hand.

    • vhanniet
      20/10/2011

      @2 – You’re right about generators: no more meta these days. And in fact they really hold true coding patterns, adapted to each project specific details.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Information

This entry was posted on 14/10/2011 by in MDD / MDA and tagged , .

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 188 other followers

Creative Commons License
IT Modernization < V. Hanniet by Vincent Hanniet is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.