I’ve struggled again and again with MDA – something just doesn’t feel right. Last night at AJUG, Jon Kern of Agile Manifesto fame presented his view on MDA. His view of MDA is at least refreshing – if CompuWare’s marketing approach continues along the lines of his approach, they have a chance. His view was very pragmatic – there is no silver bullet, and it certainly isn’t MDA, but MDA can be a valuable tool in the process. It is NOT about just drawing a picture and pushing a button to generate the app, rather it is a tool that can be used to ensure a common architecture, separation of concerns, and enable rapid development.

Now none of these things sound implicitly bad, and my use of XDoclet suggests that I don’t have a probem with code generation in general, so what’s the problem? Then it struck me that perhaps my problem with MDA is that UML is the starting point. MDA tools now seem like a natural fit for development teams already using strict UML as the starting point of their development process. For them, the MDA tool is at worst, a different tool to create their UML diagrams from, and at best, a tremendous time saver – the choice is theirs. There is still an issue of whether you really want your senior developers’ primary job to be monkeying with the tool to have it generate the right architecture, and how many expert developers will embrace this role, but that’s another discussion.

The problem comes with teams that don’t use formal UML as their starting point. UML is used to varying degrees by different teams – in addition to the strict approach, and the obvious not-using-it-at-all approach, many practitioners I know prefer to use “loose” UML to convey ideas. At my previous employer, we all had Rational Rose AND Visio Enterprise Edition. The bulk of the time, developers chose Visio over Rose. The reason? Rose was preoccupied with making sure all of the rules of UML were followed, and spawned all manner of warnings. In Visio, the developer could express the idea they were trying to convey, without worrying about whether a line had the appropriate diamond at the end of it – the point was that there was a line. The audience for these diagrams was a human audience, capable of inferring meaning and asking simple questions in face-to-face meetings to fully understand. Clearly an MDA tool must have all of the particulars spelled out for it in order to correctly generate code, else it will surely frustrate users by its incorrect inferences and assumptions.

Vendors will suggest that any team can benefit from MDA. The cynical side of me responds to MDA by enjoying the mock-acronym posted in a TSS discussion thread, “Massively Documented Advertising”. An honest assessment of the situation seems to indicate that the usefulness of an MDA tool to a team is closely tied to their degree of UML adoption. In order to claim that MDA is one-size-fits-all, you must also prove that adoption of strict UML is necessary for all teams. MDA can be viewed as code generation where UML serves as a powerful metadata language. If you already have suitable UML, fantastic. If you don’t want to use UML in that formal sense, other forms of metadata may suffice. In some cases, even that’s overkill.