The Skeptical Methodologist

Software, Rants and Management

MDA is dead

MDA is dead, and IBM killed it.

Model Driven Architecture is dead, and the so-called champion of MDA is it’s killer. A craftsman is only as good as his tools, and due to the utter incompetency of the chief toolmaker, an entire way of developing and designing software is being relegated to the same dustbin that other such buzzwords as the “Rational Unified Process” are.

“As a great and wonderful agile developer”, you say, “how come I’ve never hard of this MDA? If it’s so great, why haven’t I used it, since I am always using the ‘newest thing™?’ Well, the answer is you probably have been exposed to it, and it’s exposure sent you into knee jerk convulsions of architecture astronomy. Find your nearest ‘Software Architect’, and ask him to explain to you the wonder that is UML. Apparently, if we draw our pretty pictures just right, the software design will just fall out. That’s MDA, using UML to create models of your software as apart of the design and development process. And despite your justified sense of nausea upon understanding it, it does have a great deal of promise which, unfortunately for you, oh great Agile developer, will never been shared with you.

If you want to know how MDA(or MDD depending on which Pointy-Haired-Boss(PHB) buzzword you want to use today) works, and be happy with it, then good God, never, EVER look at the UML standard. UML just happens to be MDA’s poor retarded younger brother who got a job with him because his mother made him feel guilty. No, instead, if you want to understand MDA, look at lisp. Or C++ template metaprogramming. Or any sort of ‘programs-that-build-programs’ approach. UML just happens to be the langua-franca of MDA, but the heart of any solid MDA approach is using the models you develop to auto-generate code. Some Architecture Astronomers out there might try and convince you that the models in and of themselves have worth, but I’m sure by now you know better. As a documentation tool alone, they are sub-par, but workable. What really makes models shine is their ability to generate code, and turn our pretty pictures into an exact replica in actual, fieldable code.

This could work amazingly well with many other modern ‘methodologies’, like agile or TDD. UML basically represents the code-base as structured text(and pictures!). It allows for comically easy major-refactorings, freeing up your coder’s time from skeleton/boilerplate work, and pretty pictures to speed up new guy’s familiarization with the system(as well as automatic documentation and something to impress your customer with…) Auto-generation alone won’t get you integrated with modern approaches like TDD, instead you need both forward and reverse engineering capabilities – transforms that take a model and turn it into code, and transforms that take code and turn it into a model. This allows your architects and coders to work in the same code-base, the coder looking at code and the architect looking at pretty pictures, and neither is none-the-wiser.

But therein lies the problem – hackers and architects do not want to be none-the-wiser. Even if you can show both camps how they can easily work together, respect eachother, and not be so damned arrogant about their differing approaches, they won’t do it. Instead we run again into one of the deepest and most ugly underlying human anti-patterns: People would rather be right than get things done. If a product doesn’t ship, but the designers can claim that their process was flawless, most people would be happier than if a product did ship, but those people’s feelings were hurt. Hense we get these huge rifts between the designing and developing communities, and just as huge amounts of rework as architects attempt to accomplish something in pictures that ought to be in code, and coders completely unaware(and tripping over themselves as a result) of good design practices.

For some reason, we coder’s let MDA get gobbled up by the architects, and since the architect’s try their best to never code, the code auto-generation(that is, the magic beans that make the whole endeavor worthwhile) are stuck between two divorced parents. And since Mom thinks we’re over at Dad’s and Dad thinks we’re over at Mom’s, and we(code auto-generation) are actually out smoking pot with our friends, we’re the one who suffers. Architects continue drawing pretty pictures that have virtually no worth, and hackers continue barely scraping by any major system.

When architects go into their ‘architecture conferences’, they hear these sales pitches for tools like IBM’s wares. RSD, RDA, R-something-something, basically are all the same package, and since IBM’s the biggest pusher behind MDA, you’d think they’d be a top notch shop. But they also know they don’t have to sell their tools to the coders, they just have to sell them to the architects. So as long as the pictures look prettier than everyone elses, it doesn’t matter WHAT the tools actually produce. Besides, isn’t it the coder’s job to manually and demeaningly translate the architect’s design into code? Who needs code auto-generation when you have cheap new-hires?

June 2, 2008 - Posted by | Software Methodologies | , , , ,

3 Comments »

  1. Wow, you’re drawing a quite accurate picture of what my MDA experience has been. I particularly liked the reasons-behind analysis🙂

    Comment by Ignacio Coloma | July 14, 2008 | Reply

  2. It’s been dead since like, VGA came out. Technically speaking, though, all the MDA video modes still live on in VGA hardware.

    Comment by Windrla | July 26, 2008 | Reply

  3. Aaah, I love the schpeel about how MDA will generate your code for you from a few neat diagrams. What rarely gets mentioned in the brochure is that MDA requires a great deal of programming. The diagrams from UML don’t work by themselves to represent the complexity of a problem domain. UML wasn’t made for executing the complexity of a full problem domain, that’s why it doesn’t work like that when you try.

    One should read closely — OMG’s MDA includes a little mentioned footnote called the “Action Language”. That’s where the programming has moved to. After all, the business domain problem of “If this is true then do that, else do this 10 times” has to be expressed somewhere. So soon enough the misery of having to code in an MDA Action Language around a UML model in experienced. Of course there is no standard Action Language as yet, so best hope that your MDA tool vendor is friendly about licensing costs).

    MDA is old now, and has never been fully baked by OMG — a few snake-oil salesman still push it as a “code generator” — but you’re much safer to look at a pragmatic model driven development methodology instead.

    Comment by ModelDrivenMadness | September 12, 2008 | Reply


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: