Bite me? It's 'byte', and that acronym is Binary Interface Transfer Code Handler Surprise! It's Monday again! The weekend has evaporated once more, so pour a coffee, steal one of the expensive executive biscuits and tuck in for another tale of reader woe in The Register's Who, Me? feature. Today's tale is a hybrid: part On Call and part Who, Me?. It is, however, 100 per cent "there but for the grace of God …
Yeah, they make up for it, though, by taking the long way round. French doesn't have words for some things, so you have to explain what they are using words it does have. Can't think of any examples right now, but stuff like "logic analyser" is probably a fair example. French would have is as a "machine for displaying digital information" or some such.
This post has been deleted by its author
This post has been deleted by its author
>(morte pronounced "more" etc.)
Ahem. I'm terribly sorry, old bean, but I don't think the froggies do pronounce "morte" as "more" as you have suggested. Don't worry, we'll pardon your French. You may be mortified to learn that "morte" would be pronounced "mort." You may morosely note that "mort" would be pronounced "more" in that morbid language.
I do believe, however, that the name of the late great Mr Pratchet's novel, "Mort" would be pronounced "mort."
Tally-ho!
boot == boo-t
book == buh-k
As a West Coast Merkin, I've never been to Worcester MA but I've made several friends who lived there and in Baaahston. They pronounce it Wuhsta.
I grew up (mis)pronouncing it as War-chester. I'm from the southwest USA originally.
And then my Canadian friend pronounces is Woostar ("boot" sound), just to add confusion.
When I lived there, the locals pronounced it Wooster with the "oo" as bigmacbear says, from "book."
That was back when the Paris Cinema was a disreputable smutty theatre downtown. City Hall spent years wrestling with the Paris to shut them down. The Paris added lime Jello and jumped right in.
Massachusetts resident here...
Quincy - KWIN-zee
Revere - ree-VEE-ah
Boston - BAW-stun
...and for the Canadian gent above:
I love visiting Quebec, because I can practice my French. For some reason, though the locals seem to understand me, I cannot comprehend a word they're saying -- it sounds like French, but it's all jumbled!
Luckily, the food is wonderful, no matter what language it's ordered in.
:-)
I've had the same conversation endless times speaking to devs about the test data they set up. \It invariably ends up in a UAT environment as there 'wasn't time to build one from scratch so we cloned systest' and then the same thing happens again when training environments a built.
even if it doesn't If I'm asked to front up a demo at a Project Board I know that any offensive data will pop up in front of the senior execs and I'll have to spend the next hour explaining hot it will never hit the live system / website.
I once made a test gearbox model (for unit tests) in some engineering software I was working on that required the insertion of an elongated flexible mounting device. I called the part "Rubber Dong". It took two years for anyone to notice. I like to think it made it into a customer release somehow. There's far too much professionalism in the world, if you ask me.
Colour me square, but I just don't ever type any inappropriate language in to any work-related application, even if nobody else is going to see it. There have been too many cases like this (anyone remember "Dear Rich Bastard"?) and the momentary giggle isn't worth the risk.
My thought, not being a developer, reading this was isn't this the sort of thing you'd grow out of pretty quickly. Certainly, writing programmes (amateur) a few decades ago, I did do something of that sort in debug steps for the first few projects. But then I settled down to putting something more useful to me when the programme section ended or fell over- basically the comments. "This is the bit that adds up the hours" * being far more useful than "fuck fuck fuck".
*I'd written a programme in the 1980s that collated and added up flexi-time and reported how many flexi-days could be taken, how much could be carried over etc. within the council's rules, for a girlfriend who worked for the council. It worked beautifully and could have saved her a load of the time that she spent every weekend adding up the hours etc. She never fucking used it. preferring to sit there with her bits of paper and adding it all up herself, divide by etc etc..... It was an interesting learning curve for the callow 20something year old me. About people, not computers.
As an 18 yr old, I had a summer job as an accounts clerk. One bit of it was boring as fuck, so I wrote something in Lotus 1-2-3 that did it all for me, just had to fill in the rows in the sheet each day; when the head accountant saw it, she went white as a sheet and told me to redo it all again, this time using the calculator.... (and no, not some fancy accounts calculator with a printer outputting an audit log, just a regular desk calculator)
I'm in a heavily regulated industry, and have had this happen several times. 4-function calculator is allowed, with no paper trail, but Excel isn't - unless the specific workbook is heavily locked down and thoroughly inspected and tested by specific authorized personnel. Then any changes to the workbook (aside from the typed-in numbers) have to be handled through version control...
I see where this is coming from.
I remember there being lawsuits over things like early Excel not "inserting lines right" when inserting lines at the end of a summed column. Things would end up not being added up and no one was the wiser for a long time.
So it had to be Excel's fault. Couldn't be the user's fault for not testing the workbook after modifying it.
That is the kind of thing that happens when you don't have the locked-down version management stuff in place. Given the risks its a sensible trade-off. Merely blaming the user for not testing it is like blaming a Tesla driver for not paying attention to the road when on autopilot. Yes in *theory* they should, but in practice they very predictably don't.
"It was an interesting learning curve for the callow 20something year old me. About people, not computers."
The lesson, of course, being that people don't like change. If the new system doesn't work the same as the old system then it's too much effort to have to learn it. This applies doubly so when replacing a manual system with an automated system. Step one when designing a new system is to ask the users what they do, how do they do it and why do they do it then make sure the new system works the way they want it to.
I agree that, and have argued extensively about not designing new software on the say so of a management team about what the staff do, how they do it or what they need to be able to do it.
But in this circumstance it's more that people have mastered a complicated procedure ( and this was insanely complicated - with all sorts of rules about when and how many Flexidays can be taken in exchange for how many hours) by following a set of rules that they don't actually understand they will cling to that procedure until the heat death of the universe - because they don't dare vary off the path they are following- because they don't actually know where it leads. They're Red Riding Hood off to Grandma's cottage by following the path. And anyone offering a better way that will get them there quicker is the Big Bad Wolf.
(Also, don't try to help a girlfriend).
{{Waffle mode on}} In preparation for a revamp of our order processing software, the management asked the uninvolved developers to host a series of informal user requirement meetings with the people who would actually be using the software. I hosted a couple but was never given the opportunity to pass on any feedback from those meetings.
So we now have a management designed system and complaints about its functionality can be brushed aside with a "You had your chance at the design stage".
So many times, this sort of crap.
When I started out I was doing temp admin crap that involved keying in account card numbers from a box of plastic 'credit' cards and checking the name on the account matched the name on the card. So, something like 16 digits, confirm, read name, quit out of record, repeat. If it doesn't match, pull the card from the box, put it to one side and carry on with the next card. cards in ascending numerical order (Lunn validation). Both I and my colleague cobbled together terminal macros that did "quit, increment last number, confirm", and then we'd read the account name to check the match. 7+ hours a day.
We got through the boxes way faster than they were expecting and didn't believe we'd checked them all until we demonstrated what we'd done. Then we got bollocked for not following their instructions exactly...
Another instance from about 11 years ago, I was seconded from development to the systems admin team to cover for staff shortage (long story). Part of the roll first thing every morning was to check that a set of jobs had run successfully on the server. They did this by manually reviewing the scheduler database and ticking the entries on a sheet for every job successfully run each day. Took about 30-45 minutes most days.
I built a version of the tick sheet in excel, set it to connect to the scheduler database and match job names pulling back the job status for the current run date, then populate the next column with a tick where the job ran successfully. Took less than 5 minutes to open excel, run query, check the right jobs were all ticked, print it, walk to the printer, walk to the hole punch, walk to the shelf with the binder and file the report. The manager lost his mind 'cos how could that be a proper check? Thus demonstrating his effective ignorance of how any of the technology his team controlled actually worked...
This also points to another all too common management phenomenon. Effort ==success.
The staff members who who appear to be slogging away doing what has always been done will get approval, pay rises and promotion - irrespective of actual productivity and effectiveness (within broad boundaries).
Efficient staff who find better ways of doing stuff and achieve all that's required of them and more within the standard working day are seen as dangerous slackers - even though their productivity exceeds the sloggers. This, in part explains the ( pre-Covid ?) suspicion about working from home. Those managers need to see effort, not outcomes. Home working can see measurable outcomes - but not effort. It also explains the popularity among some management for installing key logging and screen viewing etc software on computers used for home working. It's the time bashing the keyboard that matters - not the outcomes.
My theory, supported by experience (arguably), is that those managers are themselves sloggers -promoted through effort not achievement or imagination/innovation. Not very bright or efficient they work hard at doing what has always been done - and doing lots of it, making sure their staff do the same And their managers ditto, to the top.
Sounds about right. In another data entry experience I was told I was being 'too accurate' in a data entry role because it would take me 4-5 minutes to key in data from a paper application form, where my team-mates would do them in about 3 minutes. Completely ignoring the fact that, my next task in the day was to go through and amend the new applications (at around another 3 minutes per application) returned to our team by the underwriters because they had too many mistakes in the original keying. Let's just say it was rarely the applications I originally processed which needed rework, and there was a reason they brought them to me when they returned them...
Years and years ago ( at the time of the Woolworth's fire in Manchester - we were on the next block) I worked a few weeks at a mail order company. Our job was to stuff little slips of paper that customers had filled in from newspapers into the right place in plastic wallets stuffed as tightly as they could possibly be, in alphabetical order. They were quite random and I have no idea why they weren't already in those wallets, I guess they'd been located and used somehow and had to be replaced.These were packed insanely tight so it was impossible to get the papers in and the plastic cut into your fingers each time. It was a truly horrible job- and you could see why they used temporary staff. The papers were in laminated layers. They'd be in order for a few days worth, then get more and more random until that bunch of workers got fired and a new set rolled in. Which meant that by and large these files were useless. They had to be that tight to save space. It was a big old building and the space was used really poorly. But there wasn't really a shortage of space. Just that they had always done it that way. What is interesting in the context of this thread is that the system clearly didn't work. Most of the stuff was way out of place, they had to employ staff to recruit new teams of cheap workers every six weeks or so ( that's how long we lasted - though I'd stopped even pretending to work about two weeks before). And there was no way anyone could have located these bits of paper except by pulling a whole section of wallets and checking every one until the right name appeared.
But there was clearly no intention of ever reviewing this system.
One product I worked on had a reasonable level of swear-words in the assertion strings (that could pop up when something happened that shouldn't be ****ing possible). Someone decided this needed cleaning up in case a customer saw it, and entered a task into the tasks database "Kick the shit out of <product>". WTF because that kind of phrase was involved.
but I do know of an error message that referred to a rather big-boned PM's dismissal of a rather pedantic German coder's scenario.
*years later*
Client: "What does this dialog box mean? "Wobbly Wilson says this will never happen! [OK]"
I got in trouble for an address in BELL END once, but was let off once I showed them a map of Rowley Regis. But I did get a "no answering back allowed" bollocking for using the word 'niggardly' on a teleconference once. I'm still seething.
I once worked on a project where the client insisted on an audio capability (to play nice tunes on startup IIRC).
I suggested to the firmware designer that we shouldn't let this opportunity go to waste, and provided him with a file of HAL saying his signature line: "I'm sorry, Dave, I'm afraid I can't do that"
When the machine was booted in maintenance mode, and an error occurred, Hal told you about it.
There was one place I worked (briefly) that had a lot of developers working on the same (extremely old) code base. It was good practice to tag each new script with your name, the date that it was authored, and what the code was supposed to do. The usual good practice stuff.
One day I came to modify a bit of code. I couldn't work out what it did, and all of the variables were variants of swear words. I scrolled to the top of the code file to look for the author, then leaned over to one of the senior programmers and asked "Who's Wilma Dickfit?".
The senior programmer (a good-natured ageing metal-head), leaned over, read the header note without a change in expression, then shouted "Oi, Wilma!" at the far corner of the office. Everyone else turned to look at one mid-twenties programmer who had turned beetroot-red :D
Apparently he had a bit of a reputation for immaturity, and an inability to learn from experience.
I came across an error message in 's VME operating system Kernel - this was in the kernel stack not a GUI error
'I don't know how we got here and we are running at ACR2 so I think I better crash the system'
ACR2 was the Kernel / Microcode privileged layer with unrestricted access to memory and all devices. When I started laughing at a Kernel error message I knew I was a real diagnostician
The admin console of Novell Networks allowed for the sending of IM's to people. Didn't get used very often, except for a couple of the PFYs to annoy each other. One day this was occurring, so one PFY logged off to (he thought) put a stop to it.
Unfortunately the IMs are based on user IDs assigned at login, and when someone logs off that ID is often immediately assigned to the next user that logs in, if it's within a few seconds.
So ……..that was why a senior manager called up to ask why his PC has a message in the middle of the screen saying "STOP IT!!!!".
Could have been a lot worse though!
For the uninitiated, accessing help on the System/36 required the user to hit the F1 function key. Users were trained that if they were stuck, pressing the F1 key would show some text to tell them what to do next. Simple stuff.
I remember when pressing F1 could magic up some help in lesser systems, too. Even in Microsoft Windows!
It seems no longer to be fashionable to know what you're doing, or even to be able to find out.
And even available help pages don't help anymore, anyway.
They'll inevitable contain instructions on how to print and such.
But won't even mention the several obscure menu items that seem to serve only to make the programme come to a grinding halt. Or how to perform some key programme functions that don't seem to have a menu item anywhere, or how to stop an essential function automatically rotating the page before it's printed or what to do when you get an error message saying that "formatted lists can not be sorted" or some such thing........etc etc etc.
Back in the late 80's at the start of my career, the company I worked for were selling Northstar Dimension systems. These were big boxes with S100 backplanes into which you could insert terminal cards that you could plug terminals into and ran Novell Netware. The main box had a floppy drive and option for a tape backup unit. Terminals could request use of the floppy drive (if no one else was using it) by typing in a command. We received an early sample of the Dimension 386 box and some fancy new 286 workstation cards to play around with. I decided to install some software on it to see how it worked. So I typed in 'request d' on my terminal to request floppy drive access, then typed 'A:Install' to run the installation program. Unfortunately the disk was corrupted and I got the dreaded 'Data error reading drive A: A)bort, R)etry, F)ail?' message. At this point I'd usually type A and go find another copy of the disk, but for some reason I typed F. I was then greeted with the message 'You fucked that, didn't you?' Several further experiments revealed that on a floppy error, pressing F always yielded this message. Cue one phone call to our mortified Northstar rep. Needless to say, this was patched in production firmware.
A boss of mine (we were working for a big government department) asked the guy from the customer who was our liaison what the system should do if a low level user tried to access the admin functionality. "It should tell them to bugger off" came the reply. The boss then wrote an assembler program that slowly wiped across the screen, displaying "BUGGER OFF" in large red letters on a white screen, while my contribution was a bit of code that played the Monty Python theme as it was writing the message. We were both very proud of this, until the system was being demonstrated to the bigwigs from our and their departments!
At a print-and-mail house I had the job of implementing the workflow for the production of a national building supplier's commercial paperwork. They'd been bitten pretty badly by being tied into SAP, so when they sacked them and took everything in-house for processing, they were very keen on being able to lift and shift print and fulfillment. The bloke running it was very switched on and produced clear and complete specs that were a pleasure to work to, plus he was a very cheerful Brummie who liked cricket and beer ... we got on nicely, which was just as well.
The one thing he couldn't get properly organised was testing, so we had to jump on the opportunities to test that came along at pretty short notice. Everything went well and we were approaching the end, with the monthly reports being the last thing to test - a few Excel spreadsheets FTP'ed over and loaded into their DB with a cron job. Part of the spec for these reports was that the name of the print supplier should be changeable and fit within a range of so many to so many characters. He rang up with the opportunity to test this just after I came out of a particularly unpleasant meeting with a power generation company and our Director-Buffoon, with many decisions going the wrong way as far as I was concerned. He was particularly keen to test the limits of the field lengths and our company name was three characters, so we'd already tested that - could I just make up a name fitting the required number of characters, simulate a print run and generate the reports?
It was half past six, it's raining, the bus goes soon, the pub was calling loudly, the boss had been a complete fool and now this - you can see where this is leading. The limit to test was fifteen characters so I rattled it in, set the job running, I'll look at it in the morning. If I hurried, I'd catch the bus. I hurried and caught it. Pub.
Next morning, my hungover backside hadn't quite settled on my seat when the phone rings and my marra from the building suppliers is sounding a little concerned on the phone. He's got some concerns with this latest test, could I have a look? An email pops up and I open the spreadsheet with him still on the phone. Got it open? I think we have a problem. My eyes eventualy focus and there, in lovely SHOUTY CAPS is the name that I'd rattled into the report and FTP'ed over to their *production* servers.
Print provider: SHOWER OF TWATS
The bastard let me look at that for what felt like ages before he pissed himself laughing and told me he'd been in early, cleared the record from their production server and, since the last test was giong to be sending the reports through to production ... we were finsihed.
A truly top bloke. Back then you could afford to go to the cricket, and we arranged to meet him at the next ODI at Edgebaston and bought him a couple of pints (which you could afford at the cricket, back then)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2023
