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.