Model-Driven Development: One Curmudgeon's View

Let's define some terms. By "model", I mean a higher-level abstraction of some problem domain you want to study. It might be a small-scale version of a new wing for an airplane that you want to test in a wind tunnel. It might be a stick model of a new building that you want to show your client. Or, it might be an abstract representation of a domain that you want to support with software. The model hides the less-important details to simplify model construction and to aid comprehension, yet it gives you something to work with.

By "Model-Driven Development", I mean the attempt to drive the whole software development process with these higher-level domain models. That means, in part, that you generate the implementation code from the model and rarely write any of the code by hand, when possible.

Now, some people use a broader definition of MDD to include any whiteboard diagrams, glossaries of terms, etc. that we create. I think we all agree, at the very least, that developers and stakeholders should occasionally draw such informal diagrams and define their terms, both to think through particular conceptual problems and to build a common understanding of the problem being solved. In this minimal sense, we all build models.

But I'm concerned with the more restrictive definition of MDD as a somewhat formal process of defining models of the domain from which we generate the application. I will give the advocates the benefit of the doubt and assume that it can be made to work, but is it really the best approach?

First, if such models are really complete enough to generate the working application, then their notation is essentially a programming language, as Uncle Bob remarked at a panel discussion called Model-Driven Development Face-Off at the Dr. Dobb's Architecture and Design World 2006 conference, which got me bloggin' about this topic.

This brings us to our first decision point about MDD. The model could be just above the level of the implementation source code or it could be at a very high level of abstraction, say a Platform Independent Model (PIM), to use the Model-Driven Architecture(r) term. (Yes, MDA is an OMG registered trademark...) We then push a button and a transformation process generates the implementation code for a particular platform, say a particular wireless phone configuration running on the Symbion OS on an ARM processor...

Indeed, some of the panelists want MDD to eliminate the tedium of writing all that code, like yet-another "for" loop and other boilerplate. This is a worthwhile goal (unless you like writing "for" loops; in Ruby they are kind of nifty...), but is it achievable? Can we invent a modeling language that succinctly captures all reasonable variants? If so, will it be graphical or textual?

Note that this is the first time that I mentioned graphical notations. You probably thought of UML diagrams as soon as I mentioned "modeling", but they aren't a requirement for modeling.

In fact, I contend that such a successful modeling language won't be graphical, except perhaps in limited circumstances, like UI builders and maybe "end-user programming" tools (an interesting specialization that the panel discussed briefly). With UI builders you can literally manipulate the thing you are building. With end-user programming tools, ease of use and intuitive metaphors trump almost all other concerns.

Why won't the general purpose language be graphical? Well, I worked for a Well-Known Software Tool Vendor(tm) for a few years building a UML-based tool for J2EE developers. On the plus side, it worked as a "wizard" to eliminate the horrible "XML sit-ups" that J2EE developers live with... at least until you had to tweak the XML in some way that the tool couldn't handle. So, you ended up learning the configuration file formats anyway.

On the negative side, it was simply faster to write code, period, especially with a good IDE that offers code completion, on-the-fly error detection, wizards for some of the more tedious steps, etc. So, when it comes down to the practical question of what gets the job done faster, especially for someone beyond the novice stage of experience, textual code wins.

But wait, if a picture is worth a thousand words, then shouldn't drawing be faster, even if it's more tedious than typing? It would be faster if this metaphor were literally true, but what it really means is that we get the gist or big picture of a concept through a picture more quickly than through a verbal description. Unfortunately, computers don't do big picture. They are literal-minded to a fault. They demand the 1000 words. I claim that expressing the details with a graphical notation (UML or otherwise) actually requires more effort than using simple text. Furthermore, I've yet to see a graphical notation that completely and succinctly captures the textual details in a typical requirements document.

I don't think it's just a failure of the tooling or the graphical elements. We've been trying for decades to get it right; it's simply a limitation of the "software physics" (an Uncle Bob term).

To summarize for emphasis, diagrams are most efficient for representing the big-picture, but text is most efficient for representing the executable details. So, prefer text.

I'm betting on text and for inspiration, I follow the excellent examples in Ruby and Ruby on Rails of succinct, yet highly expressive idioms, packed with meaning, yet as flexible as necessary to support all required variations.

I'll define my requirements in the form of executable tests and let the tests drive my development process. When I want to program at a higher level of abstraction, I'll invent a Domain-Specific Language (DSL) of some kind, expressed in my chosen programming language, and I'll implement all the tedious stuff once, behind the facade of that language. For me, the code is the model. If I can build a complete database-backed web application in a few hundred lines of Rails code, why would I diagram everything first?

So, I guess I am a modeler, since I use textual DSL's all the time and the occasional UML on a whiteboard. Okay, I said it. Guilty as charged.

I suspect that one reason that diagramming approaches remain popular is that the people using them are mostly embedded and real-time systems programmers who are stuck with C and C++. Instead of expending our energies building inefficient diagramming techniques, why not invent better programming languages for these users?

This is my first blog as a new Object Mentor. I'm proud to be here. For my earlier blogs on Aspect-Oriented Programming, etc. see http://blog.aspectprogramming.com.

---

!commentForm