So, “writing code” is stupid is it? Well what will we call writing the requirements in a form that the code generators can understand and why will it be easier to get the requirements right?
I like code generators. I couldn’t live without my IDL compiler. Or generators that write the grungy database access code or generators that make it easy for me to make SOAP calls. Even the ghastly #import COM wrapper generator has its place. But I’m sorry, I just don’t buy this “In the future, there will be robots!” view of code generation. People will be writing code for a long time to come.
As Dev Hawk says “they’re only good for redundant tasks.”. To write general purpose, application level, code generators you need to be able to have nailed down the language that you want to use to drive your generator. It needs to be solid and unambiguous and be able to specify all of the variation in the problem space that you’re modeling. So to achieve a simple modeling language you probably need to restrict yourself to a problem space that you fully understand. That’s fine and dandy as long as you realise that all you’re doing is raising the level of abstraction involved. Of course, the problem with raising the level of abstraction is that abstractions tend to leak.
Ian talks of replacing a the “small army of generally not well skilled developers” that can be found in most organisations and who are “churning out a mass of ill-specified code through a poorly managed process” with some nirvana in which we “capture the requirements of the model” and have a code generator that can “consume the new model and generate appropriate code”. Well, yes, and I’d like fries with that.
Though I do believe that one of the problems such organisations face is their horde of under skilled developers I think Ian’s missing the point. In these kind of organisations it is often very hard to get the project sponsors to agree on the requirements. In the environments that I work in Ian’s solution wouldn’t really help much. Sure we’d generate all the code from a nice requirements language but since the business would still refuse to commit to things, argue amongst themselves and change their minds; we’d have a code base in our requirements specification language that’s being maintained and changed and hacked and which will rot just as well as a code base in C++. Sure there may be less of it, but it still represents the same amount of business knowledge, the specification is smaller but denser. Less needs to rot for the same amount of business value to be lost.
Personally I think that Ian’s trying to solve the problem in the wrong way. He points out that the problem he’s found in these organisations is that the armies of developers build a complicated mess of ill-specified code and then let it rot. Since this code is ill-specified and poorly managed I don’t see how replacing the code writing part helps us. We now have ill-specified, poorly managed code generation scripts…
I’m not convinced that business is ready to be grown up about the requirements process just yet. So personally, I’d try and stop the rot rather than just allow fewer people to build more quickly. Stopping the rot means getting people to accept that code that doesn’t have tests is broken. I don’t care what language you use, write tests. Once you have your tests you can change your code with confidence and that allows you to work with the business at the speed that they change their minds…