Lasagna Code is like Ravioli Code, but using several layers of code.
You can't just replace one layer with another, they are are tangled together.
I think one problem with Lasagna Code is that it often has a handful of completely un-tangled layers (perhaps in which dependency only goes in one direction), but each layer taken individually is a Big Ball Of Mud. It's as if folks created rules for how layers should interact with each other, and as long as they follow those rules, anything is fair game -- there is little or no Information Hiding within a single layer. The result is that it is simple to replace an entire layer, but still difficult to replace individual components within a layer.
Perhaps a solution is that if you decide you want a layered architecture, then each layer of lasagna should have the characteristics of Ravioli Code.
Joe Celko claims to have coined the term "Lasagna Code"; anyone know whether that's true?
He said: "I coined the term "lasagna code" in my column in Information Systems News (now Information Week) in 1982 for a occurrence that was well-known among people teaching structured methods. In those days, we were worried about "spaghetti code," which referred to programs with indiscriminate GOTO statements that jumped forward and backward in the program. This tangled structure left you with a path of control through the program that looked like a plate of spaghetti."
"The standard solution was to replace the GOTOs with nested IF-THEN-ELSE statements and switches that were layered so deep and had so much redundancy that you had a path of control that looked like a plate of lasagna instead. When you have a program with complicated logic, you really should make a decision table and code from it."
From www.dbmsmag.com 
A type of Pasta Code.
See original on c2.com