Your reference is not my reference

This week we had a discussion at work. It was about reference IDs. When a system calls the webservice on another system, sometimes you need to specify a reference ID. One such case is with asynchronous webservices. The system does the call, but does not get an immediate answer (other than: "Yeah, we're working on it"). And at some point in the future the system gets a call from the webservice (a callback) to return the result of the webservice. One way (and in my opinion the easiest way) to deal with this is to have the system send a reference ID with the original request and have the webservice put the reference in the asynchronous result. This way the system can correlate the result with the request and process it.

But as we found out today, that's thinking in "functions". Meaning that calling a webservice function and getting it's results is an operation that's completely separate of anything else. Any other thing can occur between calling and receiving a result and after you get the results, if there is a process, that ends that part of the result. But for some calls we need to think in "processes".

Our system is like a webservice bridge. We expose a generic interface to commercial systems and we consume very specific interfaces from technical back-end systems. So when a commercial system sends us a request, we map it into a specific request to a back-end system. This way the commercial system doesn't need to know all the gritty details of the technical system. Also all of our calls are atomic....except for two. Normally the commercial system deals with the process and it has never had any effect on our system. Until we needed to support a certain function that did. Now in my opinion the biggest problem was caused by a faulty design of the technical back-end, but it did expose a pit-trap we could fall in ourselves now that we are designing a new interface for the commercial systems. Sometimes you not only need to know what request was responsible for the incoming result, but also which commercial process it's part of. This is required if you need to perform certain steps in order and the technical back-end system also needs to follow-up on an earlier request with a follow-up request.

So we had a discussion about this. Do we take the reference form the commercial system and pass it on to the technical system. Out-sourcing the generation of references as it were? I was opposed, because I think a reference should only have meaning to the system that generated it. If we use the reference from the commercial system, we give it a meaning it shouldn't have. Also, if some time in the future we add more commercial systems there is a chance (and knowing Murphy it will happen) that more then one commercial system will come up with the same reference and then we have a problem.

My take on the whole situation is that we apparently need both a "function-reference" and a "process-reference". We generate our own function reference and use the process reference of the system that guards the process. This could be our system, in which case we generate the process reference, or it could be a commercial system, in which case we just take the reference and pass it on.

The blame game, or: It works on our end.

The system I'm working on is in the end-to-end testing phase. It's being tested for the past 2 weeks or so and today the testers ran into an issue where request that they sent from the first system  timed-out. Their view on the issue: It's our problem.

So we did some problem analyses. We checked some log files, but we never even saw a request coming into the webserver. Then I sent the same request they we're trying to do and it got accepted, it got processed and they even got the callback to notify that the request had been completed. So we established that our system worked. Even the engineer from that other system agreed to that.

So the engineer went to check on stuff. And at the end of the day I got an e-mail that basically stated:
"We checked everything. The request is correct and we have the correct URL configured. So the only conclusion in that is must be a problem in [the system I work on]. And we'd like them to solve the problem ASAP."

This reminded me on a joke I read in David Platts excellent Why Software Sucks...and What You Can Do About It.  It's a joke about Microsoft in  a chapter about Microsoft. The short version is something like this:

A Microsoft engineer goes into the army and needs to shoot at the shooting range, but he misses every time. The drill-sergeant  gives the Microsoft engineer craps and tells him to do better. At which point the engineer holds his finger in front of the nozzle of the gun and shoots his finger off. Then he points the bloody stump towards the target and says: "Well, it comes out here alright, so the problem must be on their side".

This is exactly what I thought about when I read that e-mail and it's this kind of shortsightedness  that really pissed me off. A good engineer, in my opinion, always assumes the problem is in his code. Only after very careful examination and testing should you state it's probably a problem on the other side. And even then the engineer should fully cooperate in finding out the problem. After all, it's not like we're competitors. We're all building parts for the same product and work in the same company on the same goals.
With this kind of thinking we'll never deliver a good system.