I had an internship some time ago with a Large Company, and the codebase I was working on was very enterprisey-Java. It was really painful in this regard: an huge number of different classes, many of which were alternatives to each other, and pretty much everything was applied via homebrewed dependency injection. I didn't know this sort of thing had a name, but I think "ravioli code" matches perfectly.

One of my first tasks was to make a minor change and after an hour or so I still had no idea where the code was that needed changing. I called my manager over and he spent about 40 minutes trying to find it. He did, eventually. The change I made then took about 10 minutes to write and test.

That's 110 minutes of intern time + 40 minutes of manager time for a 10 minute fix.

I was going to suggest the term "Polenta code".

It's like that, but even smaller pieces. No more than one or two lines of less than 80 characters each (including indentation).

Orzo code? Couscous code?

Should a well-designed codebase contain special places where "things really happen"? What about the other places then?

I think the 'ravioli code' moniker is really a slight on good code. It just takes some time to become acclimated to the style of having many smaller pieces. That said, over-engineering is real. Unnecessary layering should go away.

I think the 'spaghetti code' moniker is really a slight on good code. It just takes some time to become acclimated to the style of having one long codeflow path. That said, over-engineering is real. Unnecessary assembly should go away.