Generated code is great... if it was generated by you,or you fully understand the generated code!

Imagine the following situation:

You have been working on a large project that has been around for years and you need to make a small change. The change seems insignificant so you dive in the code only to find out that the code change has to be done in code that was generated by a "tool". Now there are several possibilities:

1. The code was generated but changed by hand afterwards
2. The code should not be changed by humans, but should be regenerated
3. All of the above

Case 1:

the code that was generated is probably pretty big (otherwise it wouldn't have been generated by a tool), contains a lot of duplicated code and is incomprehensible for any human being. So you're making a change to code that you don't understand, which is by definition "programming by coincidence".

In other words, you're screwed, because you have no idea what you're changing and even if you get it working, you have a bad feeling about it because you don't know why it works.

Case 2:

Cool, you just have to run the tool that generated the code, change some settings or configuration, re-generate, and you're done. Only, where is the tool? Does it still run on my machine? (it used to run fine in 2001 on a Windows NT machine, but will it run on my Vista workstation?). OMFG!

In other words, chances are that you're screwed.

Would you trust your mission-critical application to a code generator that may no longer work in 7 years time? I'll let you answer that question for yourself.

Case 3:

The worst case scenario is a combination of case 1 and 2: code that should never be changed by hand has been changed. You should really re-generate the code, but that would overwrite all manual changes.

Now you're really screwed. Welcome to software maintenance hell...

Which leads to the title of this post: "Wizards are evil". Inspired by a piece in the book "The Pragmatic Programmer" (a must-read for any developer). It all comes down to this one statement:

Don't Use Wizard Code You Don't Understand

A snippet from the book:

"Some people feel that this is an extreme position. They say that developers routinely rely on things they don’t fully understand—the quantum mechanics of integrated circuits, the interrupt structure of the processor, the algorithms used to schedule processes, the code in the supplied libraries, and so on. We agree. And we’d feel the same about wizards if they were simply a set of library calls or standard operating system services that developers could rely on. But they’re not. Wizards generate code that becomes an integral part of Joe’s application. The wizard code is not factored out behind a tidy interface—it is interwoven line by line with functionality that Joe writes.[1] Eventually, it stops being the wizard’s code and starts being Joe’s. And no one should be producing code they don’t fully understand."

I couldn't agree more.

Let's say I needed a data access layer and I found this great, fancy tool(*) that generates all the data access code for me with one click of a button. Sure, it created 100,000 lines of (duplicated) code, but it worked perfectly.

Knowing that this application would have to be maintained for several years, and my business depended on it, would I feel safe?

NO. I would constantly worry about what would happen if any of the above 3 cases would occur in the future.

(*) Although some people will think I am referring to LLBLGen, I am not. LLBLGen is a superb tool (I even own a license), and it does have the problems I'm describing here, but there are lots of other products that generate data access layers that are a lot worse (does LINQ for SQL ring a bell?)

•