Ah, Model driven software engineering. Great babble that has come out of engineering schools but never produced any considerable outcomes outside of academic papers. Remember working with a client in the late 90ies that had decided to buy all Rational Rose products from IBM. It was one big version control hell.
Seems like there are some pretty good ideas there in principle, so it would be unfortunate to dismiss their work because maybe it wasn't ready for engineering applications in the 90's.
You're right, code generation is not a new concept, and the fact that it isn't used more indicates that most developers who have experienced it find that it creates more pain points than they're willing to deal with:
- It tends to be done ad-hoc, often by that developer who left the company two years ago, and now no-one now really knows how to improve it, but they aren't willing to throw it away either due to the re-work required to move away from the generated code.
- The generated code is ugly, or in obscenely huge files.
- Developers can too easily find their handwritten code overwritten, without even a warning.
- Otherwise simple tasks are complicated due to the generated, "impossible" to change, code getting in the way.
- Code is generated off of models in formats which don't play well with source control management software.
Despite these pain points, over the years myself and people I have worked with on LOB projects, have found it invaluable and contributing not only to very substantially faster delivery times, but, more significantly, resulting in substantially improved software quality.
Without trying to make my comment about promoting it, the above paragraph is why a bunch of us, all of whom had experience with code generation, decided to create a startup to build a product to which overcomes all the above stated problems.
So I am very interested to hear more about your experience with your "big version control hell", because we feel we are well aware of that problem and feel our solution is good, but that's just our own opinion.
I grow weary of the spate of X-driven-development methodologies that have sprung up over the years. They try to simplify the problems faced by a very complex analysis and construction process down to a single thing. I don't think it's ever one thing...
That's the fundamental issue, though, isn't it? Complexity. Trying to manage all complexity through an abstraction that cuts across multiple domain readily results in "domain impedance".
And here's the rub: any decent programming language will let you recreate the productivity savings of code-generation or the automatic tooling, but no automatic tooling will help you handle the problems of being unable to articulate the domain problems. In practice the automation pushes against your domain models and provides no help in resolving the impedance.
Maybe you've heard the expression that "the second 95% takes as long as the first 95%"... premature optimization resulting in an incorrect framework choice will frequently make the second 95% impossible.
