Working on a large and multi-tiered software project, I just found a recurring anti-pattern to be occurring in the code. I coulnd't find its definition in Wikipedia or other sources after a quick search, so I would like to ask you if there is a known anti-pattern for our current situation. I'll explain it both in the general way and by providing you an example.
In general, this anti-pattern could be called like the Italian expression "scaricabarile" (lit. passing the buck, avoiding your responsibility and giving it to someone else under you).
If there are several people on a [sub]project, and they are organized in a chain of responsibility, someone on the upper levels could decide to deliberately avoid resolving a design problem and leave it resolution to the person next to him, who could repeat this and ultimately "leave the last developer in a mess of development complexity". The anti-pattern appears when it's discovered that if the person on top of the chain resolved the problem on his own, much less work and rework would have been done by people under him.
Real world situation (in general): you are developing a middle-tier service which handles calls from front-end and has to perform several calls to different back-end services (a DB, a web service, a file storage, outsourced services...) which are not very well documented. When you get an input field you immediately can't handle on your own, instead of asking further information you simply put it in your front-middle-end interface and require the front-end guy to supply you with this parameter that will be passed unprocessed to the back-end. The front-end guy may have to perform several calls to services to get a single value that could be else obtained by the middle-tier with few calls/instructions.
In my case (assuming that in the middle-back-tier interface all values are considered to be string, and please don't comment on that becuase there are reasons), I discovered that the back-end services require fields such as order, flagDescription which can be thought to be respectively an enumeration of ascending, descending, and a boolean.
One of the problems is to encode the enumeration. What does the service accept as values? ASC/DESC? A/D? 0/1? Only BE developers know.
In fact, we ultimately discovered that the original ME developer was too lazy to ask for detailed information about the possible values of these fields. He instead put them in the front-middle-end interface as two strings, leaving the FE guys angrily questioning "where do we pick values these fields?".
I'll describe another case with a fictional example: suppose an outsourced back-end service define an operation as doSomethingOnAPerson(string socialSecurityNumber, string phoneNumber, Date birthdate), your Persons DB table identifies people by a unique ID and contains all of these information. At a certain time, FE knows only person ID and a bunch of information insufficient to make a complete call. However, the middle tier exposes the same signature as the back-end instead of a simpler doSomethingOnAPerson(long personID) which can be implemented as a DB call followed by a service call. Since ME is already deployed, this forces the FE guys to request a rework for a new service to retrieve the missing information to call the middle end services, or in other cases request that the service is re-developed to change the signature and perform the missed operation. In general words, the original developer didn't take the time to resolve the [very simple/simplified] problem of obtaining the required information from the smallest information of data available, but decided to pass the buck to the FE
In a few words, a better design and much more attention could have prevented both situations. In fact, the first also led to troubles when switching from a mocked environment to integration testing.
I would like to explain the team that we did wrong by passing the buck between ourselves rather than solving problems.
