At my company, we make hardware for analyzing network traffic. There's some really neat use of FPGA-accelerated packet matching, which interfaces with some beautifully written parallel-processing software, crafted with deep understanding of CPU cache coherency and OS kernel buffer management. So I'm told, anyway, by the "Core Tech" team who write the stuff. They truly are the greatest software engineers we've ever employed - more highly qualified, better paid, and with benefits including visits from a company-employed massage therapis
You get the picture, anyw
So when we got the opportunity to interface with their system, we were thrilled. Finally, our lowly Java-based mediation system would get some glory, albeit reflected from the Core Tech t
I actually got to meet the Lead Engineer - an imposing fellow, with a goatee beard and shiny bald pate, which he covered with a trilby hat. He placed The ICD in my hands: "You will conform to this. No changes are possible, because we've already shipped this to our customers." Not a problem, of course. The interface seemed clear enough, with messages defined as Protoc
ol Buffers, with some surrounding framing records. Some messages carried XML definitions, but these too were clearly defined with a precise XML schema.
A few days later, my tech lead wandered over, looking puzzled. "I'm sure I'm doing this right," he said, "but the probe keeps dropping the connection." Sure enough, after every message: "Connection reset by peer.
I put in a call to the man with the trilby, who snorted down the phone. "Did you even read the ICD? I know you guys have your agile processes, but in my team, we write precise specifications for you to follow." Feeling chastised, I paged through the specification, and sure enough, on page 37, footnote 2, it said:
(2) one message per connection
My tech lead and agreed this didn't seem very efficient, but then, mostly we used XML and RESTful web services, so who we
re we to criticise.
A few days later, my developer hit another snag. Under testing, the system seemed a little erratic; depending on exactly what was sent, the probe sometimes seemed to ignore our messages. Not wanting to interrupt the Core Tech team again, we debugged for a day or so, and then in desparation sent a Wireshark capture over to the Lead Engineer. A matter of minutes later, he shot back:
"RTFM. P18."
Chastened, we turned to page 18, and again, in paragraph 3, it said: "Messages must not span packets."
We looked at the PCAP file, and lo and behold, we had been stupid enough to allow Java to span some messages across multiple packets. My lead developer isn't sure how to fix this one, so I suggest he leaves it with me, and moves on to finish implementing the specificat
A few hours later, while I'm googling the correct use of "writeBytes()", my developer is back again. Wordlessly, he shows me a packet capture, where the probe is sending him truncated XML. He looks visibly upset when I reach for the phone - we must be ruining our reputation as competent engineers. So we go back to the spec, combing through it line by line. Then we see it:
"No packet shall exceed 2048 bytes."
We decide to call it a day - neither of us wants to call the Lead Engineer.
The next day, we try in vain to find an alternative solution, but to no avail. We really need that XML. So we try the path of least conflict: We raise some JIRA bugs.
Two weeks later, they're closed "Fixed". We get the new software and ICD. The change log reads:
"Updated for the GXS team, who can't follow a simple specification."