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