Peter Friese (of openArchitectureWare, AndroMDA, and FindBugs fame) recently blogged some thoughts on the merits of model-driven software development (MDSD); his thoughts triggered a variety of thoughts and reminiscences of my own.

The Fallacy of Speed

The first thing it reminded me of was the “faster is better” fallacy. Peter points out that the question, “Is MDSD faster?” misses the whole point of MDSD. Not only do I agree, but I’d take it a step further by claiming that focusing on the speed of development misses the whole point of software development in general. I can’t tell you how many times I’ve been badly bitten by some code or design that was thrown together “just to get something working,” both of my own doing and the doing of others. The unexpected (and usually undesired) resiliency of “prototype” or “hack” code and design is one of those critical lessons they don’t teach you in college but just about any cognizant, reasonably experienced developer has learned via painful experience. To be honest, one of the most frustrating situations I’ve experienced throughout my career is dealing with developers (and their output) that simply do the first thing they think of when facing a problem; very few of us are good enough to produce the best (or even a good) solution with our first thought and attempt (I’m certainly not good enough to make good on that wager very often, and I’ve been told I’m a better than average developer :-). So I was glad to see some other people blogging about that issue.

Fade the Noise

The following quote from Peter also resonated with my own philosophy:

“Model driven development helps you to concentrate on the relevant parts of your software (i.e. the business logic) instead of having to care too much about the architectural plumbing around the business logic.”

This reminds me of one of the big reasons I love Smalltalk – its syntax is so utterly simple yet expressive, it frees your mind to concentrate on the purpose and logic of your code rather than its structure (it is immensely more succinct and focused than the mess that has become Java syntax, but that is another blog post altogether). I suspect that it is this familiar trait of fading out the noise that appeals MDSD to me; I often long for the joy of developing in Smalltalk, the syntactic silence is probably the biggest reason why, and MDSD give some of it back to me.

Map Analogy

I really like Peter’s illustration of abstraction using a subway map. I would extend that by saying Domain-Specific Languages (DSLs) are very much analogous to maps, in that they focus on a particular aspect and fade ,or hide completely, the details of other aspects. That is not to say that those faded/hidden details are not important, just that in the current context they are more distracting than useful. Going back to the analogy, having a street-level map of the city of Boston is useful if you are driving or trying to find a particular address, but would probably be much less efficient if you were just trying to figure out where to catch the Blue line subway to get to Logan airport.
Sometimes you need to super-impose or combine DSLs to get the “big picture,” but the ability to focus on just one aspect at a time is a key benefit of DSLs. Again back to the maps analogy, check out the different views provided on this page and see how focusing on one specific map yields a different experience than using the super-imposed view.

UML Considered Harmful

Finally, I’ll comment on Peter’s reference to graphical languages or notations. He and I clearly share a distaste for UML as the one and only modeling language, as it is often pitched by tools vendors. I often say of Skyway Builder that it’s biggest benefit over other modeling tools is that it has no UML, and I sometimes get a perplexed reaction. The point is, building a system from UML strikes me as the worst of both worlds:

• Like coding, it is (typically) quite tedious and time-consuming, requiring sophisticated tools and  specific knowledge/training to do effectively. In other words, it is too low-level.
• Like requirements analysis (as it is typically practiced), it is usually incomplete and lacks sufficient detail to actually implement a usable, functional application. In other words, it is too high-level.

So, with UML-based modeling, you get this uncomfortable conundrum where you spend lots of time and energy and money on a task that requires technical knowledge, and yet what you end up with can not be executed or easily turned into executable product. Kind of like the Buttered Cat Paradox.
So I’m quite happy that Skyway does not use UML as its language notation. In fact, when I first came on board the Skyway team, I was quite skeptical of MDSD because most of the so-called modeling tools out there are little more than glorified UML-specific Visio wannabes. Needless to say, I now understand the power of a textual DSL complimented by a strong tool that focuses the user on solving his domain problem, fades the noisy details into the background, and produces a real, functional application rather than just another specification that someone has to go and implement. That is what we have built in Skyway Builder!