Editing Generated code - an anti-pattern?

In the 1970s, Ivor Tiefenbrun revolutionised the hi-fi world. Perceived wisdom held that, since the loudspeakers produced the sound, they were the most important part of the system. So, for a given budget, the largest portion should be assigned to the speakers.

Tiefenbrun disagreed. He believed the most important part was the input. Since the sound originated from the record (vinyl in those days), the most important component was therefore the turntable. So he invented the Linn Sondek, revolutionising the industry with a product that is still for sale today.

Tiefenbrun's lesson came to mind at the code generation 2008 conference in Cambridge – stimulating content in a fantastic setting.

During a discussion in Anneke Kleppe's session, a delegate asked about good practice for editing / modifying / augmenting generated code. The usual solutions came up (Generation Gap pattern, protected blocks) but for me the answer is clear: any kind of modification to the generated code is bad. It's an anti-pattern, there only because of deficiencies in the input and/or lack of customisation in the generator. It's often necessary, in many cases simply because the input language doesn't allow the full model to be expressed (this is true for most mainstream UML tools). But we should be striving to fix the real problem – insufficient or incorrect input – instead of trying to fix the symptom. We need to apply the 'Tiefenbrun principle'.