Having to maintain software with few if any comments is hard enough when it's a few thousand lines of fairly straightforward code -- I've been there, and I've religiously overcommented my own software ever since. But with large programming projects now easily generating hundreds of thousands of lines, pulled together from many teams and including previous software, the problem can become overwhelming. Even when code is adequately commented in the beginning, changes made subsequently to the software are rarely reflected in the documentation.
MDA should be self-documenting. The idea is that to make an application, you build a model of what it should do according to business rules, and includes the kind of data that'll be handled. Many programming projects start like this with models on paper: the programmers then turn the paper ideas into working code. MDA has a different approach: the model is described in the Unified Modelling Language (UML) that can be automatically converted to runnable code. This happens by stages, so that multiple different programs for different platforms can be generated from a single platform independent intermediate model.
Because most of the development work happens in the model, changes to the application will happen there -- and the MDA development tool will then generate a modified program. Programmers will at all times be working on the latest, most accurate source of the design ideas behind the program, rather than the program itself: not only will this be much quicker, MDA's proponents say, but much less prone to error.
Can it work? Although MDA is conceptually finished, there are still gaps in the standard and much discussion going on, especially in the trickiest bits: how do you turn a conceptual model into real code without going through the head of a programmer? And then, how do you test what you've done and verify that it works? These are the details that can take a good idea and damn it to irrelevancy. In the past, 4GL languages, computer-aided software engineering (CASE) and many other loudly trumpeted breakthroughs in programming have either lost relevance or been scaled down because their promise on paper failed to translate into a workable system that programmers found more useful than infuriating.
There's no doubt that, at some point, programming will become a matter of designing a model and waving a magic wand. Whether that time is now -- and whether the efficiency of the MDA process consistently matches or equals the old ways -- can only be answered over time. Case studies are good -- suggesting 35 to 50 percent productivity increase with no loss of code quality -- and products like CompuWare's OptimalJ enterprise application development environment are provoking much interest. This could be the last time that programmers can ever answer questions about their code with "no comment".







Talkback
Sounds nice. But.....
But it's messing with rice-bowls: There are legions of coders who know how to make code do things, but who either can't think or aren't interested in thinking in models.
But it's messing with aesthetics: A good chunk of the people who got into this game did so because of the love of seeing behind the curtain. This kind of approach turns the curtain into a solid steel door with a biometric lock.
But it's limiting to innovation: Once you turn the curtain into a locked door, you set specific standards for innovation, and thus decrease its rate. Visionary individuals will be prevented from deploying solutions because they don't fit into the modeling framework.
I've no doubt that modeling-driven approaches will become central to software development. But if they expect to make decent progress, it's advocates will have to address to these cultural and pragmatic issues, lest the inevitable failures cause it to be damned as yet another wave of hype.
Ask any coder a simple question ?
Have most of the projects that you have worked on been ..... ?
A) A brand new system
B) An upgrade or add-on to an existing system
Yep, you've guest it! The answer would be 'B' in most cases.
Why oh why, has the software industry never really caught on to this fact ? Programs are almost never these days written from scratch! This is why .Net and Java do not rule to the roost.
UML is fine, but what if an system was never written using UML in the first place. Have you ever tried reverse-engineering an system into UML ??? I have just done just that! and it's taken 6 months on a medium sized enterprise app.
The only way I can see the coding industry speed up is to help us easily move the past foward into the future.
Till then, I'm going to carry on, carrying around my 15 year old copy of "Code Complete"