IT Modernization < V. Hanniet

software model driven approaches

True story of a MDA paradox

Based on a true return of experience.


This company has built an efficient MDA/MDD life-cycle based on UML and a robust MDE tooling. They outsource part of their new applications development. They offer to their IT services providers to use the company’s MDA tooling, and even offer to educate them and provide MDA expertise and support.

Recently, a provider told the company: “We started the project with your tooling and it worked very well. But now we are under time pressure and we think we will go faster by finishing the project in a classical way without the MDA life-cycle”. They did it and delivered the project on time.

The company analyzed the quality of the delivered application and told the provider: “The application does not conform to our quality rules and will be hard to maintain”. The provider answered: “You are right and we know that it would not have been like that if we had kept on using your MDA life-cycle. But on another hand we have delivered the project on time. However, now that we have respected our contract, we can make an offer to put back the source code into your MDA life-cycle to improve maintainability and rules compliance.”

The company will probably accept the proposal… Funny, isn’t it?


The paradox: MDA life-cycle would produce better source code but would be slower than coding “by hand”.

This statement is often reported by MDA users. Beside the one I describe above, one frequent case is that during maintenance operations, say a critical bug appears at a badly chosen moment, when the developer find the bug it is likely that he will fix it immediately and won’t try  to investigate any global consistency with other parts of the system nor, of course, any documentation lack or specification missing. And not speaking of fixing a model.

Of course, in emergency situations it’s not a big deal to fix the bug at any cost. And we can re-synchronize later source code, models and code generators. We even can build a “re-synchronization tooling” that will help putting back things into order (we already did it several times at Mia-Software).

We could also say that having to deliver a new app just in time is also a kind of emergency case. But, wait a minute. What does a new dev project is expected to deliver? An app which seems to “run” on nominal cases? An app which successfully passes UAT? An app which conforms to development rules and quality criteria? An app which is easy to maintain?…

There is only one good answer: it depends on the requirements, and consequently on what is in the contract between the stakeholder and the development team. And conforming to the planning is anyway only one part of the contract.

Efficient MDA is never slower than hand-coding if the contract has requirements on software quality, software architecture, and software maintainability.  We may have good reasons to choose a short-cut bypassing the MDA life-cycle but we may be aware that there is always a quality counterpart.

Featured image taken from

4 comments on “True story of a MDA paradox

  1. modelpractice

    Lets face it:

    most customers (I know) can only deal with linearly ordered criteria like time and budget. Things that have a more complex structure (like quality, arch., maint.), and thus require slightly more competence and responsibility to judge than an ape needs to peel a banana, are too heavy to handle for them.

    Ok, sounds pessimistic. Perhaps I’ve always been dealing with the wrong people?

    Have fun

    • vhanniet

      I think you’re far too much pessimistic on “customers” (people) sense of responsibility ;). Say they are responsible, the matter is: responsible for what? The answer is (too) often: responsible for short term results. And the real matter about quality, architecture, maintenability… Is long term sustainability. Long term vs short term. Not a new problem, nor specific to SW.

  2. TY

    I think, what ever, if that provider can succeed — that is, the project is able to be implemented by dividing into these steps: coding (by hand) to get a prototype that have the functions required, quickly; modeling (reference to the prototype) and generating code with the MDA tools to gain a final product that has the functions and meeting other requirements to quality, maintenance – it seems implying that the MDA tools and/or the methods, the architecture have certain problems, isn’t it?

    • vhanniet

      Hi TY,
      In fact it seems they used the MDA tooling to produce the SW architectural artifacts and the middleware glue, then completed the project with hand-written code. Fact is than they succeed, at least enough to complete the project’s contract.
      You are right in pointing out that if the MDA tools would have been more efficient they would’nt have to disconnect them. But the story don’t tell enough to understand if the MDA tools would need enhancements, or if switching to hand-written code was just a way to cut down project costs by doing less work (but enough to achieve project’s goals)…

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s


This entry was posted on 15/09/2011 by in MDD / MDA and tagged , .

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

Join 187 other followers

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