I transferred into a new department about three weeks ago, which involved a move across the office of about fifty feet. There was a transistion period agreed between my old director and my new one, and I have been madly clearing my desk since then.
Last week I took off half the week so I could spend time with my visiting friend Paul the Globetrotter (I will post later on the events arising a out of that once I have recovered my mental balance and the hangover has worn off) and used that to notify the office facilities manager that my (digital) 'phone number needed moving.
It hadn't happened by the time I returned to desk clearing ops on Thursday.
On Friday, I arrived to discover that while the phone number hadn't been transferred to the new handset, my voicemail password had been disabled for my convenience. How lucky it was that my cellphone battery chose that moment to peg out and that Mrs Stevie needed to yell at me about the Stevielings upcoming Middle School graduation ceremony. Thank you the brain trust in charge of the phones.
I called Sam the Phoneguy and he assured me the work had been done. I pointed out the phone number hadn't moved an inch from where it had been since the building was opened. He told me the phone had been "forwarded". I replied that that wasn't what I ordered and that it wasn't going to do the job because the phone would ring at my old office and voicemail would be taken (and indicated) in my old office. He replied that the phone number had moved. I explained that that was complete b*ll*cks on account of how I was sitting in my old office looking at the phone which clearly displayed my number, and that it had rung twice that day in my old office forcing me to be there to answer it rather than in my new office. This witty exchange went round about three times before the penny dropped and Sam told me it would be done by COB Monday.
I arrived on Monday and went to my new desk. Five minutes later I was dragged back to my old desk by Mike the Shaman over a program I wrote that a vendor was having problems with. This program is simply a robotic "launcher" that allows people to use a PC to run a legacy greenscreen transaction, and during the writing of it I nearly ate my own leg in frustration because the transactions it launced had to be modified by a team from another political entity.
Warning! The next umptytump paragraphs are filled with boring, dense technical flappery with minimal humour and a triple helping of incoherent rant stirred in. Read at your own risk.
The first act of the manager involved, Ms Lackabrain, was to do nothing for six months and claim afterwards they had been "working dilligently". The second was to fail to use her own agency's project life cycle processes, which caused her to badly underestimate what the job entailed and do a simple conversion required by their team as a precursor to the real work but none of the required extra stuff needed to accomodate the finished project (as envisaged by them). As her final act of sabotage, she put the whole thing under the control of a person with little experience in the language used1, no experience OLTP2 or DPS3.
That last wasn't such a disadvantage since DPS, a world standard since the early 1980s and a genuine boon to productivity, had not been adopted at all by the agency in question. They had gone with a home-grown "version" of it, which was slower, more dificult to deploy and so complex it wasn't even used by everyone in that agency.
All this wouldn't have mattered if the agency in question hadn't insisted that the transaction code not be extracted and purpose-built OLTP versions built, but that the same transactions run as both greenscreen transactions and OLTP services. To do this required the adoption of DPS, which includes a nifty work-around so that people who already have DPS can quickly move into the OLTP world without throwing the baby out with the bathwater. Of course, the manufacturer, Unisys, envisioned people using it as a temporary work-around while they retooled their software with bright, shiny, new purpose-built OLTP services. Thus, expedience was the watchword when making engineering choices in how to do the job4. They could not have imagined that anyone would actually begin designing a new deployment around the technology, because that is what we in the trade would call a Nitwit Solution.
Why? Well, the effort of installing DPS into an exsisting transaction requires the separation of the "buisness" logic in the program from the "presentation" logic (which is the bit DPS replaces), and if you are going to do all the work of identifying and separating them, you might as well spend two seconds turning the business logic into the OLTP service (which uses a much simpler presentation mechanism) via a build script that produces both it and the old greenscreen program. You'll be going that route in a couple of years anyway for Azathoth's sake. It should come as no surprise that the I.Q. Brigade chose the worst possible way of implementing when I add that everyone involved works for the government.
Anyway
I spent months with my "technical" contact developing this bloody thing. At no time did she develop enough enthusiasm for the job to actually pick up a (digital) manual and start to get informed about the subject matter, but this did not stop her from lecturing me (thirty years of programming, lots of it in Cobol and some of it in DPS) on how I should be doing the job, to the point that it often took four or five e-mails to get her to actually go and ask someone who knew what they were talking about to tell her how to do the part of the job we were involved with that day. Nothing beats trying to tell someone tactfully that they don't know what they're talking about while they are telling you in plain English the exact same thing. I eventually found the person she was consulting, and began dealing directly with him, which caused a deparmental row and Ms Lackabrain to demand a conference phone call in which Mike the Shaman was called as witness for the prosecution5. Mike, being about as sick of the whole thing as I was proved to be a hostile witness, telling the I.Q. Brigade that I was right and they should stop whining and get moving.
Anyway
The job was eventually finished and passed to the vendor, who sat on it for about 6 months. This was long enough for me to get my transfer and (more significantly) for Ms Einstein to "get creative".
The problem was that the I.Q. Brigade had made some changes in the screens, but forgotten they wanted me to use them too and stored them as plain old greenscreen screens. This makes them unavailable for OLTP use and kicks back an error. How long do you think it took me to suggest this had happened? About a minute. How long before I could persuade Ms Einstein that since the error was a DPS error it had to lie on her side of the border? If you said four and a half hours of constant work, you'd be right. Mike the Shaman eventually found the hard evidence, along with a memo that they'd done the exact same screw-up two years ago on something he wrote. He wryly pointed out that his programs transactions hadn't been adjusted since then, and that it was his opinion that whatever they had to change next, they would end up breaking it the same way again. I believe he is right, because this crew is all about not learning from history.
Do I sound bitter? You better believe I do. I recognised that any change in the screens would cause a potential problem on day one, and during that acrimonious conference call I mentioned I asked that when the programmers changed the screens, they add us to the CC list of the change request. This, I was told by Ms Lackabrain (the manager responsible for assigning the "techical lead", not scoping the project, etc etc), was "impossible". Note that I wasn't asking for an e-mail. I was asking to be included in the distribution of an existing e-mail that was going out anyway. This was "impossible". This kind of thinking is why the I.Q. Brigade is deploying an obsolete technology to prop up an ill-conceived work-around instead of doing the job correctly, and why I now envisage that silly b*tch being hit full in the face with a bucket of fish heads every time I hear her name.
*<sighs>*
This morning (Tuesday) I rode in on a train with no A/C. Actually, that's not strictly true. Half the car had no A/C, the other half did. Apparently the designer felt that in the event that the (two year old) A/C failed at one end of a car, the whole thing could be kept bearable by the other end's A/C unit. Another win for the I.Q. Brigade there, then. Definitely not a waste of public money, these new trains6 .
And my phone number still hasn't been moved.
- Cobol, for Azathoth's sake. How they found a trainee in that language (perfectly good for the job but laughed at by the young and the restless these days) is beyond me ↑
- On Line Transaction Processing. A fancy name for getting a program on one computer to run programs on another ↑
- Display Processing System. In the old days you had to write the screen descriptions character by character, keeping a mental picture of what it would look like as you went. This did not always work well. DPS allows you to draw the screen and save it to a file so that the program can get it again each time it runs. This works very well, and so was not adopted by the people concerned until it was obsolete technology ↑
- Don't get me wrong. I think Unisys did a bang up job with this process and I recommend it to any site needing to leverage old 20th century code while they replan their enterprise around the realities of the 21st century. ↑
- Of me ↑
- In the same way that the US government aren't a bunch of lying, coniving weasles in the pockets of the special interests and Ms Lackabrain isn't a complete waste of around 3 bux worth of chemicals and a few pints of water ↑
No comments:
Post a Comment