Technology Snake Oil, Part 3: MDA

Model Driven Architecture (or "Cartoons to Code") is the ultimate culmination of the vision of UML. Let's draw the software with diagrams, including decorations to represent logic, then click a button to generate the code. A laudable goal, but far short of reality.

The only real success stories with MDA are for very limited problem domains, like embedded software. Here's why: consider the cash register at McDonalds. The number of items is very limited, and the number of things you can do with them are very limited. This is well suited to a pictorial (in fact, an ideogrammatic) representation. That's because the concepts on display are retricted to morphemes, which in linguistic terms represents the smallest language unit that carries a semantic interpretation. Thus, it's easy to create a McDonalds cash register using just pictures and make it a quite effective solution to the food ordering problem.

For complex problems, you can't break down the problem to simple morphemes -- imagine the semantic complexities of a concept like "loan" or "payment". For a problem domain this rich, you need the richer representation of a full-blown language (which the Egyptians also discovered -- they were the last MDA success story, and they eventually abandoned it!). Trying to cram rich semantics into a pictorial representation so that you can create software that abstracts those semantics is absurd.

In fact, trying to cram the entire world into a strict tree-shaped hierarchy isn't much better (see Programming, Object-oriented). At least OOP has more flexible semantics, and we keep forcing solutions to this hierarchy problem with inventions like aspects, which cut across the tree-shaped world we've created (because stuff in the real world cuts across trees). So, where do we go from here?

Let's solve it the same way mankind (including the Egyptians) did -- create language! Language is ultimately the only way to handle the rich semantics of the world around us because that's what the people stating the problem domain use to state the problem. Which is why I'm so geeked about Language Oriented Programming -- building domain specific languages that are as close as possible to the problem we're trying to solve. LOP done right encapsulates the low-level details of a language like Java, allowing developers and others to work at a higher level of abstraction. We've been mired in curly-brace languages too long -- we need to upgrade our abstraction.

MDA is the wrong direction for abstraction upgrade. It tries to further restrict our expressiveness, believing that the entire world can be graphed and you can create real software this way. Imagine for a moment the MDA diagrams (including Object Constraint Logic) for your average J2EE enterprise application. You can build it in code, with the crude semantics of curly-brace Java in 1/3 the time you could model it to the point where you can click the "And Then a Miracle Occurs" button to generate the application. MDA might work for simple, semantically unique domains, but no where near the real world.