In the future, there will be robots!

| 4 Comments | 2 TrackBacks

The code generation crowd are at it again.

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...

2 TrackBacks

TITLE: We're a labeled group now! URL: IP: BLOG NAME: Frans Bouma's blog DATE: 07/03/2003 08:25:07 AM Read More

TITLE: In the future, there will be robots! URL: IP: BLOG NAME: Eric J. Smith's Weblog DATE: 07/03/2003 02:03:13 PM Read More


I totally agree ;) Auto code generation has its place but it can't possibly be used to just generate an entire application for business use at the click of a button. One size fits all is a bit stupid, otherwise we'd all be driving the same car....

Wizards etc. are fine, no one wants to write a multi-doc hosting framework in MFC if it can be generated, but business logic + workflow is a more subtle beast, and unfortunately tends to be down to the whims of the 'business', so no auto-tool could possibly cater for all situations. And then you have things like the adapter pattern if you were to swap out MQ Series for MSMQ for example. You may want to use features that are in one API and not another. How do you cater for that? As in maths, one exception breaks the rule - you can pick dozens of holes in this.

And then garbage in garbage out - if the template that is auto generating the code (written by a person of course) is buggy, every subsequent app is buggy. So you have to 'save' your config file somewhere to regenerate your app with the new code tool/template that is less buggy. So all you've done is abstracted up your code to something daft like a '3GL' or 'xGL'. So you're still writing code.

Every bit of serious software has to be configured for whatever system it is going to run on - if the customer has some strange audit/security requirements (e.g. FSA) - where is that catered for?

It's all nonsense.

"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."
See, here you make your mistake. A 'code generator' today cranks out code because most people want to embed the generated code in other sourcecode. However, why would a code generator f.e. generate C#? It's more efficient to feed a model to a generator which creates an executable, or a library which is ready to use. Most people who think generators are only for repetitive tasks, think that generators should generate text, source. Wrong. If you think about generators as implementation machines of programming logic, it will be much more clearer why generators are the thing of the future and typing code is something that will be only used to feed new functionality to already existing generators.

Thanks for the critique. I'm not going to pretend I know how to write what I want to write but I still think it's the right long term direction. There's a lot of modelling and code generation issues to figure out. I accept that if you take a "can I do it today" pragmatist viewpoint, it's reasonable to pooh-pooh it as unattainable within the current generation of programmers.

Forget about the current crop of code generators. That's not generally what I'm thinking of. I'm certainly not thinking of simple code generation scripts - that's much too simple and brittle. Frans is correct in that I want the code generator to consume a model. I don't think the model it consumes has to be UML or something that has a 1 to 1 correspondence with the final code. It's not just another procedural language. I'd like to see just how much of the implementation a computer could derive. It's my conjecture that it can handle things like data access, forms display, form navigation, error propagation, transactional boundaries, variation points for business logic, etc. But, yes, I'm not sure how to model it (yet).

I'm not concerned about acceptance by businesses at this point. If you can make it faster/cheaper/better, businesses will adopt it.

I agree about testing. It's key. In fact testing is evolving to be more model driven. You may even be able to derive the test framework and the application from the same model. But I know that sounds like a lot of pie in the sky though.



Don't get me wrong, it's a great thing to strive towards. It's just that I'm not going to be getting as excited about it as Frans obviously is until it seems a little more likely to materialise.

I agree that you shouldn't worry about business acceptance. As soon as it works they'll come running to you.

Thanks for the testing link, looks like interesting stuff!

Leave a comment