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).

Funny image describing this

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.

Do you find a popular definition for what I have descripted so far? Can you help me find articles about this, if it has been documented yet?


1 Answer 1


I'm not sure that there is a specific anti-pattern term for the general miscommunication that is occurring within your development group; however, there may be applicable anti-pattern terms for the problems in your codebase:

This is not necessarily a widely accepted term, but for your first example, the name I give this anti-pattern (applicable when using type-safe languages) is "Everything as a String". It is poor practice and in a type-safe language should be avoided at all costs - the basis being that you have types; use them!

The second example you give is more subjective - from the standpoint of the backend engineer from an API design perspective, it may make more sense to provide an interface that accepts input that does not rely on the internal recordkeeping details (i.e., personID) for usage. I'm not sure this example qualifies as an anti-pattern; avoiding this should be considered good practice and the opposite may actually be considered an anti-pattern.

  • I like your answer. From my point of view/experience, even the "everything as a string" can be deriving to the same lack of communication and refusal of responsibility. Even in a type-safe language, a well-documented string should be "quite acceptable" rather a non-documented thing. Instead, the guys hurry to deliver something that is presumed to work or works in a very specific unit test. It then leads to the same consequences: bugs and delays, doesn't it? Commented Nov 1, 2011 at 20:55
  • An API should be well-thought out, designed and negotiated with the consumer to ensure that it provides the services it should. It should be designed with all of the features available to the language to help ensure it is not misused (it is the developer's user interface). The benefit of using types instead of strings is that types require less documentation because the behavior and constraints are intrinsic and enforced by the compiler. A good API will only require minimal documentation, and usage and constraints will be clearer for everyone as a result. Commented Nov 1, 2011 at 21:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.