If you have a mess in your code where methods are being called from one place to another in such a way where is really difficult to follow the flow of the program execution this is known as Spaghetti code. Following with the Italian cuisine allegory, if you have too many layers of abstractions this is known as the Lasgane Pattern.
I am just surprised how many times I have seen this anti-pattern in place! It's typical in client server applications where programmers have learnt about the importance of a N-layer architecture and with a bit of cargo cult programming they end up overusing it.
In software, a n-layer architecture it's a way of separating the code of an application in different components or modules. The code will be separated around different concerns. The typical separation of components is presentation, data access and business logic. If we are talking about a server-client application another component will be added to deal with the communication between both. If you draw an image with all the components like layers one above the other with the database at the bottom and the UI on top, it looks like a n layered or multi tier architecture. We can draw arrows from the presentation layer to the database to see the flow of the actions.
This is a good pattern and basically almost everybody follows it. The problem is when developers start adding layers just for the sake of adding layers! One layer more for the cache, another one for the application etc. Then you end up with loads of layers and many of them doing nothing, just delegating calls to the underlying layer.. To make it even worse different type of objects will be used between layers (Entities, DTOs, ViewModels, Ducks, Chickens..) with the extra work of having to map from one to another. If you add to this the need to unit test every single layer you will end up with a lot of work to do just to get a single record from the database!!
If you are not careful a misused n-layered architecture can bring a lot of unnecessary complexity. My advise is to use the least amount of layers possible (And store procedures are considered a layer). Don't put layers just in case, software is cheap to change later on. Yes.. I know, architecture is not that easy too change, but still it can be done, try to deffer that decision as much as possible (maybe you can do some prototyping?) and be wary about layers.
Reference: I don't know who came with the name, but I heard about this anti pattern first time in coding horror. Though there is called Baklava Code.