Apparently, the MDA vendors want to spend my days configuring their tools to generate our framework. Another week, another visit from an MDA tool vendor, and this time, I felt obligated to ask about the wisdom of generating so much of the plumbing and telling people not to touch it, just fill in the little blanks with the allegedly simple business logic. I don’t strictly object to code generation – XDoclet and Middlegen have their place in the toolkit, and that place is mostly generating code for the mundane, cookie cutter aspects of an app.
That’s all well and good, but 80% of the development time seems to center on the 20% of the code that can’t be generated anyhow – the non-conforming data access and data objects, the intricate business rules that fork every time you talk to the end user. It’s time spent tuning the data access layer to balance performance and functionality, mucking with the MVC mappings to achieve reuse or a better user experience. In this case, I was informed that my role “as an experienced developer”, is to act as the architect of our framework, and to configure and enhance the tool so that it could generate the more custom components of our framework that meet the more intricate and specific needs.
This is very much akin to developing your own XDoclet module, which is something I’ve intentionally avoided because it’s not usually worth the time. XDoclet is useful to the point that it takes care of the little things you don’t want to do repeatedly. Few people would advise you to slap a UML modeling tool on top of XDoclet (assuming some sort of slick integration), and then sink your time into making XDoclet generate all of your code, yet that’s precisely what the vendors seem to want, and that time investment’s justified because, heck, you’ve already invested so much money in the tool. At some point, you get to the level where the code is so custom that it’s not going to be reused, and MDA tools become a golden hammer. Additionally, you can end up with so many options of how to generate the same code, you lose the simplicity the tool is supposed to provide. This is apparently the vendor’s opinion of how it should work. The other option is to use it merely as an expensive version of XDoclet that happens to have UML integration. In this case, it still gets ugly, because they want you to bind the attributes in your UML model to database tables and columns. There’s enough debate about enshrining DB mappings in your value objects for code generation purposes, but it seems blatantly messy to do this in your UML tool.
So apparently the options are either monkeying with the tool, or using it as an expensive code generator that violates abstraction. Where do I sign up? Of course the whole thing comes from the pipe-dream that we can turn software development into a turn-key, assembly line process, the same dream that’s been selling CASE and RUP tools for decades. Move along, there’s nothing to see here.
Rob's Blog - Technology, Atlanta, Startups and Stuff 
Which MDA tool are you using?
We’re not currently using any tool, but evaluating several. Much of what I’m saying does indeed refer to a particular tool, but I’d rather not get into that at the moment – we’ll probably have a few more meetings with them, and I’d rather not have baggage coming into those meetings (especially since I don’t write the checks).
I’m not categorically opposed to code generation, and it’s even possible, probable even that there are better tools out there than the simple XDoclet stuff we’re using. So far, though, I also haven’t seen a tool that seems to be worth the absurd prices they’re charging, and particularly, I don’t buy the promises they’re making. I think they solve some problems well, others not so well, enough so that I don’t see it as worthwhile to use the tool as the foundation of our apps instead of simply as a tool.
I hear what you are saying. No worries. Though I would love to get a chance to talk with you after the decision was made.
I’ll let you know. To be honest, the whole looking-to-buy-an-MDA-tool thing isn’t borne from any internal need. Essentially, it’s because the IT press hypes the products at the same time the vendors are trying to cram the products down management’s throat.
Once the smoke clears, we may not buy anything at all. Based on what I’ve seen, that’s what I’m hoping for. As you’ve suggested before, perhaps I’ll guide them down the path of AndroMDA if they’re dead-set on acquiring a tool. The only problem is that management tends to view a choice of open source as a placeholder while we evaluate commercial products.
I look at code generation directed by management with great skepticism. How the code is created and how it functions internally should be under the control of the engineering team. Project management should concern itself exclusively with customer related activities like specifying what services the program will provide to the customer.
Let me know how it goes. I suppose I should have thought that the popularity of code generation would eventually lead to management trying to shove it down our throats. Most of the case studies on the CGN have dealt with engineers who do CG for themselves unbeknownst to management. As popularity grows those salad days may be a thing of the past.
As one of those damn MDA tool vendors, I can assure you that not everybody subscribes to the simplistic view that MDA turns code generation into a process that will automagically make software development easy. What’s hard will remain hard. What’s easy, plumbing, monkey code, though, can be automated to a high degree – and it allows you to focus on the creative stuff.
Some time ago, I wrote an article targeted at developers for TSS; an updated version is here (along with a bunch of related entries in this category (those are links, BTW, hard to tell with your ‘a’ style).
Hi Jack, BTW đŸ™‚