At a site not so far in time and space from where I now happily sit, I was set the task of assessing a proposed tool. That fine tool would allow a remote and loosely coupled entry point into a real-time system.
Now that tool was coined a gateway by its vendor, and an apt name it was too. I have AC/DC’s “Highway to hell” going as I write (and the album ‘Gateway to…’).
Well, as a coder, getting an API and framework to test without doc, tools or even an exposed interface is not the best of starts. As it happens the remote interface bindings, or wrappers, were in Java. And for some reason the test system I had installed came with a Java binding client footprint – i.e. the classes [of note, the vendor would supply a hard drive with both RedHat OS and their software on. No machine, just a disk. And what was on there was really a development environment with some cleanup done before shipping to the customer. Just great]. But without doc or code, how foolish would I be?
The task was as interesting as any I had been given there (and far more so than some). So, I thought, what the heck, so how will I start?
$ javap -c -public *
Running this sort of command over the class files gave me a good idea of what was public API, though not much idea about why or how. Luckily the code wasn’t obfuscated either. So, with the assist of Apache SOAP and Xerces, I was soon on my way, hacking a connection to the server.
I wrote code that called that server, sending XML/SOAP RPC requests which arrived at their HTTP endpoint, and on entry into the real-time system, the C++ calls also returned, as did the XML payload with the results.
The result, data delivered to real-time system permanent store, queries honoured. Side effects, many. Mostly crashing of the gateway itself.
The vendor says, hey, it’s stable and sends me the doc. But rejects my request for the source. Can’t win them all.
But the Boss decides to buy the thing without asking my thoughts on the wisdom of doing such! Or maybe just ignoring my constant rants. I had suggested that we write our own version, as what we wanted to do was a tiny subset of the features offered. I could also make it simple, meaning LESS CODE, LESS BUGS.
The source arrived in the end, the comments left by the supplier’s coders suggested it was as immature as I had feared. And in final testing using their very bad doc, my conclusion was that it actually was as flawed as I had first thought.
OK, I felt stupid but I was a contractor and was therefore a hired hand. And my holidays were due. I hadn’t had a break in over a year, and even contractors deserve (need) a rest. So, just in case, I copied my code to a second location where it would be sure to be safe.
Disaster number 2. On return from holiday, one of the system administrators had apparently been trialling his new backup software. He’d written some scripts which he tested on the live systems. And without doing manual backups first. As I later discovered, his code did this.
foreach user
cd userHome
rm -rf allFiles
tar -cvf allFiles
Though not code, one might get the idea that, had the person in question tried writing some pseudo-code before hand, they might have seen the CRASS STUPIDITY of their actions. But no…
So, minus both a voice in the decision making and now minus my actual prototype code, I was somewhat disheartened.
But new work came along and projects followed their merry course.
But there’s more. A project that had decided to rely on the Gateway software had been merrily trucking along. To my surprise, that component had not been addressed until late in the game. My worry was that it had been considered at all.
I eventually got to talk to the group and suggested that an alternative mechanism could be employed. One that was simpler, in C. It would sit on the same server as the C++ real-time API that it would call. My proposal, a (very) simple socket server, as what was by then a ‘single RPC call’ did not require a behemoth software stack to service it.
Well, I was ignored a second time. How crap am I? With excuses like, “we can’t change our architecture so late in the day”, to “no the vendor says it is stable and we have the code running”, none of which sat well with my earlier findings. Groan, now not only was my prototype gone, but also my determination to provide assistance.
Needless to say, that system went into production. And one day! Yes, said system locks up. I didn’t actually know at the time what it was, but as the group raced to find out what was stopping our “Service Call” handling solution, it dawned on me just what was happening.
Client code calls gateway -> gateway calls real-time process -> real-time process dies
You would think that a vendor would have architects, developers and testers who could plan for this
real-time process auto restored -> gateway sits locked (with expectations of messages from the grave)
Yes, instead of the gateway server keeping an eye on the state of the process it calls, it cannot deal with its demise. There is never a return to the synchronous call (and we all know what that means!). In fact my killing and restarting the gateway is the only fix, and a welcome one. Our own developers had only considered that the original instability of the gateway itself should be cause for concern.
So, the Boss asks for recommendations and within a short time the interaction with the real-time system is dropped completely and the gateway is consigned to the scrap heap.
What did I learn. Sometimes you can’t help those who won’t allow themselves to be helped. Bosses will do their own thing. Project staff will stick to their programming comfort zone. Sometimes it does feel like STUPIDITY will reign supreme.
Actually I did learn that one should not expect a receptive audience simply based on one’s experience levels (like my own involvement in commercial software development for some 20 years and many, learning, before that), it does not mean that people will feel even slightly compelled to listen.
Conclusion: if it were my money or my project, then I would feel the need to cram that which leads to results, and success, down the throats of others. I must say that this same team did take on ideas I had previously suggested (a lot of excessive client SQL was replaced by SQL database Views). But this was a story about a bigger folly, one within which I had seemed useless and incapable of preventing, even when it was as big and obvious then as it is now, in this my post project dissection.
So, here’s to all those who have also tried and failed, you’re in good company ;-)
