Code Generation

The code generation movement has achieved some remarkable things over the past twenty years, but its success has been constrained by a fundamental complexity paradox.

Firstly, the tools generate added complexity, with hidden side-effects. In general, developers who manage to stay below a certain complexity threshold can often get greater interoperability and flexibility. (Bob Balahan refers to these as "lowest-common-denominator features", known to work reliably everywhere.) But code generation tools often go above the complexity threshold by default.

See my note on Simplicity and Complexity

Why do the developers of code generation tools deploy features that compromise interoperability and flexibility? Partly because they want to offer functionality they can differentiate from their competitors. And partly because they aren't always looking at complexity from this perspective - from their point of view, these features make their job easier, and any complexity will be hidden from the tool user, so what's the problem? The problem is leaky abstraction.

See my note on Leaky Abstraction

The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying "learn how to do it manually first, then use the wizzy tool to save time." Code generation tools which pretend to abstract out something, like all abstractions, leak, and the only way to deal with the leaks competently is to learn about how the abstractions work and what they are abstracting. So the abstractions save us time working, but they don't save us time learning. [Joel Spolsky]

See my note on Automation and Skill