“Spaghetti code” is a well-known phrase for software with tangled logic, especially legacy code with goto statements.
The term “lasagna code” is not nearly as common. I first heard it used to describe code with too many architectural layers. Then I found the following older reference to lasagna code with a different slant on the term.
Lasagna code is used to describe software that has a simple, understandable, and layered structure. Lasagna code, although structured, is unfortunately monolithic and not easy to modify. An attempt to change one layer conceptually simple, is often very difficult in actual practice.
Since “lasagna code” has a different usage, I propose the term “baklava code” for code with too many layers.
Baklava is a delicious pastry make with many paper-thin layers of phyllo dough. While thin layers are fine for a pastry, thin software layers don’t add much value, especially when you have many such layers piled on each other. Each layer has to be pushed onto your mental stack as you dive into the code. Furthermore, the layers of phyllo dough are permeable, allowing the honey to soak through. But software abstractions are best when they don’t leak. When you pile layer on top of layer in software, the layers are bound to leak.
Related posts:
Leaky abstractions and hockey stick learning curves
Floating point numbers are a leaky abstraction
{ 1 trackback }
{ 3 comments… read them below or add one }
Jason 07.27.09 at 15:51
This immediately made me think of some of the WSGI apps I’ve been digging through lately. It’s a useful and conceptually cool standard, but I’m finding that it’s also very easy to abuse.
EastwoodDC 07.27.09 at 20:03
If spaghetti, lasagna, and baklava are metaphors for bad programming, then what food represents good programming?
And to answer my own silly question: How about Mexican food. Seven basic ingredients served up in a multitude of different ways depending on the dish to be served (or task to be coded).
CJ 07.27.09 at 21:32
I like the Mexican food analogy, but I immediately thought of a hamburger: You’ve got the meat (the interesting code that the program is all about), the buns (a convenient, portable UI), and the toppings (interchangeable functions for pre- or post-processing). It works really nicely for the kind of code that I end up writing (data analysis/machine learning), where there’s one key idea that the whole algorithm is based on, with a whole lot of necessary but less-important code that wraps it.