complaints r us

i got a call from the boss, informing me to check my mail at the first opportunity. here's what i received:

Hello <contact's boss>,

With regards to a complaint relayed to me this morning I am reporting the following:

Nature of the problem:
Client complains that the code that used to work with the previous version of the API, does not work with the current one.
Specifically, client's code <technical details> to access <technical details>.
<technical details> are not available using this logic.

Investigation results:

<technical explanation>

This <technical details> has NOT been changed since the very first implementation of the above method back in version 1-5-0 (September 2005).

Conclusion:

Client's developers had misinterpreted the result they were getting as a change in the API behavior.

Apparently, the above API methods were never applied to <technical details> until now. Different <technical details> settings understandably produced different results: the <technical details> were not retrieved.
Client's code took an execution path that was not tested before and its
logic failed.

The failure was wrongly blamed on the new version of the API.
In fact, the API worked as it was supposed to. It was the client's code that failed to account for the conditions described above.

My conclusion has been communicated to <me>, the client's developer.

Sincerely

<my contact>

and here's my response:

<my boss>,

In the specific case cited below, <my contact> is almost correct. What he failed to mention is the distinctive lack of documentation that has caused us many problems from the very beginning. It's not that there isn't any documentation at all: the documentation is simply not meaningful, and as such doesn't comply with world-wide standards adopted for a very good reason. As a user of the API, I need to know more than just the inputs and outputs of a function, I need to know WHY we need it or HOW it works.

In most cases, I've simply had to guess at the usage for the functions we've been given; considering that there are differences between the internal names for functions and values and the <support company> application itself, I've had to spend a lot of time deciphering these same functions with our dealers, just to figure out which data we SHOULD be testing with.

"<technical explanation>"
When we began dealing with this specific bug, <my contact> informed me that I was handling it incorrectly, and that I should try instead to access <technical details>. When I tried that, I got no relevant information at all (although, according to the API, I should have received the same QUANTITY of data, I received nothing), and simply requesting that data eventually led to our application crashing because it used too much memory. That doesn't make much sense, considering the fact that we retrieve plenty more information from the other functions.

In addition to that, we suffered a few setbacks when the new version was released. Specifically, the API itself was changed, which meant a rewrite of the basic functionality of our applications was required. Not just that, but it was flawed, and that meant we had to wait until a new version was released. Changing the API structure is not appreciated in the slightest, releasing a new version that isn't fully tested is even more frustating.

In all cases, I've found <my contact> to be extremely helpful, so there are no complaints there. Singling out this incident from all the previous ones does not accurately reflect the situation, nor the nature of our complaints, so I would be most grateful if you were to pass this on to all concerned parties.

Thank you,
<me>

now, that's the politest way i know to say "go fuck yourself" in business-lingo.