Antipattern of the month #6: Code generation tools

Everybody had his cup of code generation tools sometime in life. From lightweight (appgen, XDoclet) to more heavyweight tools like EJB generation IDEs, JSF tools and MDA 'robots de cuisine'. The lightweight ones had their use but I find the second kind dangerous for mental health.

Brooks outlined the percentage of work invested in each step in the development process. That was back in 1976, so a little guess from my part had to be added to get to this chart:



Which means that it takes three times more time tweaking code than getting to the very first implementation. This is a more-or-less valid, optimistic guess.

Calendar planning, frameworks selection, UML design are things not affected by these tools, since you are going to do them anyway. The main point where this tools shine is in the initial code generation (that 16%), where most people enjoy a big misconception.

Traditionally we have learned that bugs introduced in a system are easier to fix if they are detected as soon as possible in the above stages. That is true. We have also learned therefore that a detailed design avoids introducing mistakes in the future and helps refine requirements sooner better than later. That is also true, provided that you are not a strong agile follower.

The inherent conclusion we assume is that visual is better. Wrong.

Most of these frameworks end up with some kind of Visual Programming Tool: because visual is better, you will be more comfortable drawing boxes and linking them with arrows than writing the equivalent code. This is not news, and no single tool of this kind did stick in the past. Draw a class, add five stereotypes (transactional, ehm, service, clustered, request-scoped, and, ehm, add 42 just in case), detailed attributes description and half-dozen-stereotypes relationships, which would then generate java code. This way you will have to learn things twice: how to do them in Java and how with the tool. Anyway, the amount of work remains the same since you are not addressing the essence of the problem, to speak in Brooks' terms.

The project will be condemned to deal with legacy tools for its whole life. In order to switch you will have to wait for the framework to (a) get out of beta, and (b) the tool starts supporting it, if ever. It's common practice to start working with beta libraries expected final before the end of the project, to avoid becoming Dead On Arrival. Not a real issue here since everybody is still using EJB 2, right?

Debugging: a big share of any project calendar is assigned to code debugging, that is what that 50% of testing is about. This will happen no matter what your tool vendor has promised you. You cannot avoid this. This is what No Silver Bullet is all about. Now, take a minute to consider how this code was generated: one of the big selling points is that your team do not need to know anything about the concrete technology in hands, and sorry to say it out loud, this is big crap. You will have to debug the damn thing, and it's much harder if the code has been automagically generated since nobody was thinking about readability. I can recall about some eclipse plugin that generates two persistent classes per SQL table and a green Loch Ness DAO of like two hundred lines - for each table.

Your customer doesn't know a thing about what he wants. He wants something that looks like an iPod, performs like Google and has a truly intuitive interface. Expect refactoring to happen, and happen frequently. Choose tools that promote refactor: lightweight code generation frameworks (XDoclet and such) help by removing code redundancy, but with Java 5 annotations these tools have quickly become obsolete. Any other framework I know of helps very little (if anything) to refactor, and most of them in fact get in the way big time.

There is a third kind of tools comprising AppFuse, RoR scaffolding and such. A completely different kind mostly on the "best practices" side of life, they serve as introductory architecture templates helping to kickstart projects with best-of-breed frameworks already picked and assembled in the best possible way. They help to understand the available solutions and start with something that works; it's not a matter of generating code, but assembling frameworks can be a tricky, uneasy deal. In fact, the only partial success I have seen in the heavyweight code generation tools is that they also mimic the first and third type, and as such some people keep using them in spite of the pain.

So, I only know of three types of code generation tools:

• Lightweight (XDoclet, appgen, etc): generate code using embedded comments and similar. These are being progressively replaced with annotation-based frameworks.


• Heavyweight (anything with a pretty window full of colors and buttons): avoid them as pest. They are focused in easing up to 16% of your project, leaves 35% unaffected and harms the rest. The only partial success they get is by imitation of #1 and #3.


• Architectural (AppFuse, project able, Ruby stuff): pre-packaged templates with best-of-breed frameworks already linked together, easing the pain of starting a project and making the initial choices for you. A good way to go unless you already have hired The Gurus.

Just remember that none of the three will do the thinking for you. Have a happy 2007!