True story of a MDA paradox

Based on a true return of experience.

Facts

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?

Comments

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 http://www.jordan-webb.net/abilene_paradox_pu.html