Should MDA be the Holly Grail of Agile Manifesto?

OK, I’m in a teasing mood… But let’s take the four Agile Manifesto values and have a look on MDA(*)  through these values.

1. Individuals and interactions over processes and tools
   The fact is that tools have a huge importance in MDA. Individuals, even interacting well, will not succeed if MDA tools don’t work (modeler and model-to-code generator). This is a key difference between non MDA development and MDA development. Leaving aside this key point, the MDA process globally use an Y-cycle (modeling / making generator + using generators and completing code) which benefits well from interactions between functional modelers, architect and developers. But MDA is a process.
   MDA ranks 3/5 on this scale
2. Working software over comprehensive documentation
   At first glance, agile processes advocate that source code is the (unique) material that worth to spend time working on. On MDA side, the focus is on formal specifications through models (for part of specifications that can be easily modeled) and source code automated generation. Aside from source code, models and generators have to be taken into configuration management as they hold an important part of the final source code direct responsibility. So, in an MDA project the formal relation:
   application_source_code = application_architecture_generation(application_functional_model) + non_generated_added_source_code
   leads to consider generators and models as working software parts. The happy end is that models are also documentation!
   MDA ranks 5+/5 on this scale
3. Customer collaboration over contract negotiation
   This axis is technically neutral (whatever the development techniques are, we can always choose to spend more time with end users than with buyers & lawyers!). However, one noticeable point is that MDA techniques are very useful to build mocks and prototypes, notably for UI workflows, using modeling/generating quick iterations. By drawing a quick & direct relationship between a customer exigency’s evolution and the impact on the application, MDA gives better control to the customer.
   MDA ranks 5+/5 on this scale
4. Responding to change over following a plan
   MDA is the champion of “responding to a change” challenge! Don’t forget that the main part of the application source code is generated (usually about 80% in modern languages). So, as soon as the change is described until it can be modeled and the non-modeled functional details may be given in natural (or formal) language, the change implementation is mainly achieved by launching a code generation (and completing this code with the non-modeled functional details). And the other happy end is that it almost does not matter when this change occurs: even at the end of an iteration the change may be implemented!
   MDA ranks 5+/5 on this scale

So, the result is: through Agile manifesto values prism MDA is an incredibly good choice! Looking at the Twelve Principles of Agile Software for the same challenge leads to the same conclusion. Not so surprising in fact: Agile values and principles say nothing about how to produce good code (ie code that implements a correct response to user needs and is sustainable in software life-cycle). Nothing but: the team will find a way. MDA is a process which aims to link a non (so) technical way to express exigencies (modeling) with a structural way to produce repeatable source code (generating). An MDA agile team can surely find a path to success!

What’s wrong in this reasoning? I don’t know yet, and maybe you’ll tell me. One fact however: I never saw a development project finishing in initial time frame with the whole initial perimeter implemented. Never but in some MDA projects…

(*): MDA is here used in a generic way that means using models to generate (structural) code. I could have used terms as MDD or “MDE development” but MDA seems more meaningful to me in a straight interpretation:  Model Driven Architecture.

Featured image taken from http://sanderhoogendoorn.com/blog/?p=1048