[prev] [thread] [next] [lurker] [Date index for 2006/02/17]
--VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear Great Big Smelly Piece of S... S... Software, that shall remain unnamed not to protect the guilty, not even to protect the innocent, but merely because if I have to once more utter, write, or type its German-sounding name, its three-letter acronym, or its trade name that brings up associations of both physics and topology, I *will* be violently sick all over the desk and the floor, and the cleaning lady has done absolutely nothing to deserve the extra amount of work. We have known each other for a full year now. We've been through good times and bad times - or, at least, that's how the saying goes, while actually it feels more like bad times and worse times, and I'm kinda reminded of the English joke about the doctor's son who, when asked for the comparative and superlative degree of "bad", promptly answered "bad, worse, dead". Some people might say that such intimacy over the course of an year is grounds for a nice, healthy, long-standing relationship. Some people might go steal an H-bomb, drop it into the crater of an active volcano, watch the blast from a respectful distance, then briskly walk over to the gap of the newly-formed crater, and do a double somersault - backwards - into the hot, spicy, bubbling, radioactive lava. How do I hate you? Let me count the ways... Way the First - Message Queueing. Okay, so you're based on a well-thought-out, industry standard, fully buzzword-compliant message queueing architecture from a certain bluish software and hardware company. So far, so good. But did you really *need* to take the concept of message queues, turn it inside out, marvel at the shiny bits inside, *then* turn it upside down, shake it violently, and run with it? Did you really, really have to define a separate queue model for pretty much every single query (oh, excuse me, those are not queries, those are not even messages, those are *processes* now), then squeal, throw a hissy fit, roll over and die each time somebody sends you a message with the wrong queue model? And oh, certainly, every now and then some part of you decides to send a reply on the *wrong* dynamic queue, then just sits and waits until Somebody(tm) comes along and fetches the message that nobody expects to be there - in the meantime, refusing to process any further messages, since "nobody fetched the response of the previous one yet". What's that you're saying? Timeouts? Ah, sure, there are timeouts - and pretty much reasonable timeouts, too - reasonable for your friendly neighbourhood planetologist, I mean! Way the Second - Error Reporting. Security measures? Oh, of course you've implemented security measures, no question about it! Like... let me tell you a story of many moons ago, painful as it is for me to even remember... So we're on site, fighting with said core banking system for the finishing touches of the pilot project. Suddenly, with absolutely NOTHING changed on our end, the system stops responding to our queries. Yep, we send a message, we send another one, we send fifteen different kinds of queries that worked, like, what, two minutes ago - and just like with the Fab Four, "No Reply". For two hours - two whole goddam hours - we work with the bank's IT guys, trying to diagnose all sorts of problems - all the way from network connectivity through protocols up to the system being up in the first place, which it obviously is, since no one at the bank is running around in panic and tearing his hair out - no one but us, I mean. Finally, one of the IT junkies comes up with a bright idea: "What account are you trying to use? THAT one?! Oh, it was just a temporary one, it expired today!" "Er, what?! Why didn't you tell us that two hours ago?" "I just thought of it..." "Uhm, wasn't it in the logs or something?" "Logs? What logs? It doesn't log this kind of problem anywhere, it just drops your query on the floor." Uhm. Whiskey Tango Foxtrot, over?! Now I'm not exactly what you'd call an omniscient security guru or anything, but... Correct me if I'm wrong, but if the core banking system receives - via the bank's internal network, no less - a query with the wrong auth credentials, there are two, and only two, plausible explanations: - something is misconfigured on the bank's internal network, and the bloody administrator freakin' needs to know about it - NOW! - somebody is trying something nasty ON THE BANK'S INTERNAL NETWORK, and the bloody administrator freakin' needs to know about it - NOW! What am I missing? Please tell me, what the hell am I missing? Way the Third - Fragility... or Reversibility... or Something So our application has to report the last 15 transactions on the customer's account. There's a query - uh, 'scuse me, a process - that returns the full information about the transactions on the account for a given time period, 60 at a time. We run it, fetch 'em all, the use the last 15. Of course, a Corporate Customer comes in with many, many transacions per day, and the "fetch 'em all" strategy leads to a wee bit of waiting on the line. Fine, so the query we are using has a "direction" parameter that lets us fetch the transactions going back in time. Clickety-click - ten lines changed in the code, a *single character* changed in the query sent to the core banking system. Half an hour of testing, everybody goes home happy. The next morning, five frantic phone calls in as many minutes: "We are missing transactions! We are not reporting transactions! We can see the transactions on our system, but your app does not show them!" Nah, impossible, innit? Well, let's humor them, let's go over and check. Yep, our app is missing transactions all right. An hour and a half later, after I've made each and every test known to humanity and then some, I go back to the bank's IT department, and, in exasperation, ask them, "Look, I *know* this sounds silly, but I just have to cover everything now... have you heard about any problems with such-and-such query when going back in time?" "Oh, of course! That's a known problem - you're not actually using it, are you now?" Must... not... explode... Must... not... climb... walls... Must... not... bring... walls... down... A single-character change in the query. Reverse the order that the results are returned in. Get a whole different batch of results. Yep, not only were some transactions missing, the banking system actually made up a couple of new ones, just to keep us giggling happily until the straitjackets are cut to size! Way the Fourth... oh, well, nevermind, I *really* could go on like this all day - nay, all week, if I have to - but there just ain't enough sedatives in the world, not even of the triple-distilled variety, to help me up afterwards! So, Dear Great Big Smelly Piece of S... S... Software! There was a certain Monk in a certain Monastery who came up with the idea that there is indeed a Biblical way of expressing the sentiment usually dished out as a four-letter acronym that starts with an 'F', ends with a 'D', and somewhere in the middle there's an 'O' and an 'A'; the Biblical quote in question was "Go forth and multiply!" Well, if "multiply" is extended to cover "do not, under any circumstances, create ANY ADDITIONAL COPIES of yourself, but simply use a high-power charge to create many, many disjoint small parts of you, all subtly different"... then by all means, dear core banking system, do kindly go forth and multiply! And no, I do *not* need to know when this happens - for if I never, ever hear anything about you again, it will have been an year too late! Loping off to scream, leap out of the long grass, and rip soft bits off small furry animals, Peter --=20 Peter Pentchev roam@xxxxxxx.xxx roam@xxxxx.xx roam@xxxxxxx.xxx PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 What would this sentence be like if pi were 3? --VbJkn9YxBvnuCH5J Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.1 (FreeBSD) iD8DBQFD9Yvt7Ri2jRYZRVMRArMlAJ9JZk8InMjT6CIY2iGUecPNf4fBmQCgtMfU On5sxWls/aSCBhbdBe5zjmI= =RdHV -----END PGP SIGNATURE----- --VbJkn9YxBvnuCH5J--
Generated at 04:00 on 19 Feb 2006 by mariachi 0.52