Cynical
The trouble is, even as hard-bitten cynics, we all recognise the truth of this article.
And we all know the solution --->
We're standing still. The suspense is unbearable. One of us is going to crack. On the large projector screen is a message: "The application is not responding." Facing the large projector screen is a roomful of startup dudes. Staring back at them, and situated just underneath the projector screen, is the flailing, forlorn …
It is worse -- sometimes when you search for a specific XYZ error message you get, as top results, pages like "Problem XYZ - SOLVED!!!1!" or "How to completely and permanently solve issue XYZ".
Usually, the steps are just like the ones Dobbs listed (ranging from "uninstall and reinstall the software" to "format and reinstall the whole OS"), with an additional "buy our software that will not only solve XYZ but also clean your registry, your basement, your face's skin and the nastiest entries in your browsers' history".
Lovely.
Wow, a moderate moderator! Normally, or at least usually, she should have smitten you with her godly moderator powers for questioning her obviously superior wisdom in her own house.
Remarkable. So, humble people do really exist. I've been told so repeatedly but couldn't believe it.
Well, to their defense, assuming in the above mentioned situation you weren't just a random bystander but someone they actually paid to solve "that kind" of problems, wouldn't it be justified to expect you might be able to do something about it? After all, to them it looks like "that kind" of problem...
TL;DR: If you're the IT department you have to accept responsibility for IT stuff. "Out of my control" is not an excuse when you're specifically paid to keep those things under control, now is it.
Just saying.
It isn't always the fault of the IT department.
Our IT department identified a persistent (and for us, unfixable) error in one of our [insert name of large database vendor] database's core software.
Fortunately, we had a support agreement with [large database vendor] for such eventualities, so we called up their support team. They knew of the problem, but also knew it would take a team of ten about three months to fix it, so refused to do so on the grounds of cost.
Wankers.
> It isn't always the fault of the IT department.
You missed my point. I didn't speak of faults, but of responsibility. IT problems are the IT department's responsibility, even if they are not their fault (like some rando dozer cutting the network fiber 3 blocks down the street).
Finger pointing and blaming is useless and counterproductive. Shit happens, and normally you have people who's job is to intervene and try to fix the problem, period. Only politicians and slackers argue about who's "fault" something is (understood it's not theirs).
Its worse that this. Marco, a maintainer of the CygWIN (definitely) version (probably) of vim (maybe) has added a default user path, during compilation, for the .virc file as /home/Marco/.vim/.virc in addition to changing the default location from /home/.virc to /home/.vim/.virc and I can't figure out how to report a security vulnerability because of the /home/Marco part. In leiu of that bug report, i just made /home/Marco a link to /dev/null
OK so I've installed Linux, some of the web based corporate apps are still accessible but I cant produce reports necessary to keep operation running as theirs no integration with any desktop products. unfortunately the 20+ applications that require a client application don't work at all now.
[Apologies for mangling the quote: subject too long]
At least it didn't cause an "out of range" exception.
It is never a good idea to be factually analysing good stories such as this, but I would assume that the software was good at calculating sheep, and ignored the dog. The consultant however did not ask the software to choose a sheep for him.
The shepherd says to the dog - "I want to recount. Please round them up to check the number "
The dog comes back and says "Woof! you have 140"
The shepherd says "Strange, I only had 137 this morning!"
The dog replies "Well you did say to round up!"
-----
"if the management consultant can't tell the dog from the sheep" ... no no no - in the consultancy world view, they're all dumb animals and therefore fungible resources; just like his client's employees!
The software can distinguish between sheep and dogs and hence gives the correct count - the management consultant does not do the count himself but does use his own judgement to select which sheep to take.
Personally I think it more likely he would get the count from the shepherd and use that to sell her boss the sheep-counting software plus a contract to extend it into a full sheep management suite in order to replace the shepherd.
> Joke reminds me strongly of... ...the argument over whether the tracks are deer or moose.
?? I have no idea how that comes out of Dabbs' meander.
However here in coastal Maine it can be a real point of interest. (Leaving aside the quibble that moose ARE deer, oh dear.) Deer are suburban vermin (dinner); moose are mostly loners inland away from people. So one morning there are tracks by the driveway. Compare the length of the track to the width of your hand. Track is bigger than about 4" (10cm), it was a moose.
Is it feasible to run the application in a VM? Would it be possible to snapshot the VM at a point after the thing has settled down? Then, each time you start the VM, it's past the biscuit dunking stage of the application. That is also dependent upon the application itself being able to handle the temporal shift, but that would not be too different to say the system coming out of hibernation...
Back in the days when Powerpoint was new a young lab head worked up her floor talk saved it to CDrom. Then took the disk down for her talk. Her slides had text but no pictures. She had chosen to link them rather than copy them in. Since she was no longer running it on her laptop PP could not find her pictures.
We all thought “that could have been us, phew!” and did not make the same mistake.
I have arrived at a point where I am thinking this stuff is no longer accidental*, and it is thus very likely that you simply end up triggering other countermeasures to prvenet your approach offering any productivity gain.
* If it was the odd software playing I'd call it a bug, but the longer I work with Windows again (after a 14 year hiatus, long story), the more I get convinced that the sharp decline in software quality and the resulting impact on productivity is no longer an accident. I have come across software which is breathtakingly bad, and yes, by that I mean other than Microsoft Office - there is no way any rational individual can consider almost all of it being sh*t accidental. What puzzles me most is how it ever became acceptable to waste so many computing resources on doing so little.
And also for the hardware maker, see Alister's step 8. The waste of computing resources really is immense - since memory and disk space of ordinary desktop machines became greater than I used to think were decent specs for a mid-range server, I'm sure that developers don't even consider them to be constraints any more. I don't want to go back to revising assembler code to save a few dozen bytes or a few thousand CPU cycles, but it has now gone badly the other way.
Something to remember is that the kids who graduated Uni/College and got into the corporate computer and networking world back when computers started becoming ubiquitous on desktops all over the corporate world are now roughly in their mid 50s.
Note this is managers, users, coders, programmers, systems folks, everyone.
They started commercial computer work with DOS 3.3 or 4.0 and maybe Windows 2.x (or thereabouts), and have become conditioned to the Redmond Way ... In their minds (and the generations following) it's supposed to be shoddy code, it's supposed to not be secure, it's supposed to break at the least convenient time, it will crash at random, updates will make things worse, over time it gets bigger and worse, if you turn it off and back on again it might fix it (maybe; try flicking the switch again) ... these are all enshrined in the corporate attitude.
What would be the point in building clean, simple, elegant program code that just works when the underlying OS doesn't support such a concept?
Those of us who started coding in the 60s or earlier are just left shaking our heads. Can you imagine what the reaction in Corporate America would have been if DEC or Burroughs or Sperry or IBM had made just one release that was as buggy as the code that is run as a matter of course on modern computers? Or worse, the drek in "the cloud"? The company's stock would have tanked, they would never have been trusted again, heads would have rolled ... ugly wouldn't even begin to describe it.
But these days? Navigating through crap, buggy, crash-prone bullshit has become business as usual. Because THAT'S HOW COMPUTERS ARE SUPPOSED TO WORK! Ask any manager. Or coder under 50. (Thankfully there are still a few real programmers out there in each generation.)
So why bother paying money to fix it? The shareholders will just bitch about the expense.
I have no answers. I'm not sure there are any. It's probably too late.
Just recently, had the issue of a new application (yet to go live) that did not react well to the loss of a network connection. As the person most familiar with that application had recently left, it fell upon me to look at the issue - It needed a small tweak of the code, as the code would otherwise enter a never-ending loop and end up writing to the log until the space dried up.
As the release deadline was getting near, the senior PHB started attending the planning meetings and daily stand-ups. He over-rode the remediation work for this - saying if it happens, the support team can deal with it.
The inevitable happened - the downtime was significantly more than the time that would have been spent correcting the issue when discovered. At the next sprint, I told one of my colleagues that I'm going to fix it, which I did, he reviewed the PR, we told the QA manager who got it tested, but not the PHBs.
I was toying with a post along the lines of this very observant comment, but this says it all.
What to do? SOMETHING has to be done. We can't go on like this forever, surely?
One thing, which will earn me many downvotes because of those on this forum having vested interests, is to look back through history in other "trades" that became "professions". We kid ourselves that I.T. is a profession, but it is not controlled in the same way that, say Architecture is. Bring in reforms whereby only licenced practitioners can install production code. The issues there are (1) This is a global issue: who do you think should oversee it? (2) How do you deal with the "fabric" that such code will sit upon? You can't suddenly rip up the internet, the cloud, or OS's such as Windows. You would have to use that fabric as a "tunnel" for your licenced code. However, the problem there is - mindful of a recent article on this forum about the impossibility of providing a sequence number for Azure transactions - the incredibly asynchronous nature of the fabric. How long do you wait for "eventual consistency"? The latency of such a system would thus be intolerable. (3) This will exacerbate the dearth of coders. Is that a bad thing? Judging by the extant quality of code out there: not necessarily.
You might counter: how dare you make such comments when your own code is no doubt so flaky. Well I have worked on systems where the specifications have been written by highly regarded software houses: working within the frameworks of those specifications, but there have been so many fads that these organisations continually churn their specs to comply with the fad du jour. One of the useful contacts I did have (now sadly deceased) was a practitioner/consultant/lecturer on SSADM. I took over and maintained some of the systems he designed within the limitations of his clients' budgets and level of tech at the time. So I'd suppose that has given me some insight into how things should be done.
TL;DR It's probably too late. Sadly, Jake, you may be right.
Another minor problem - how do you prevent anyone with a PC and the inclination writing software, even if its macros in Excel?
Its on a par with stopping people doing their own minor electrical work say running an extension.
IT is as far away from being a proper profession as a Taxi driver is away from an airline pilot.
A Taxi driver passes their driving test once at the beginning of career, and can drive any car they like until retirement. The consequences of failures are normally minor, most accidents don't result in any long term consequences for either driver of vehicle, except for slightly higher insurance, which does nothing to raise standards.
Airline pilots on the other hand have to take a far more extensive qualification, and are re-tested every few years, they also need to become qualified on each new type of plane they fly. Failures are generally a lot more serious and call in to question both the competency of the pilot and the design of the aircraft, lessons are learned.
We can either put up with cheap low quality software on unreliable operating systems keep driving us in to a ditch, or pay more for professional quality engineering of applications and operating systems. Unfortunately, I think we all know which one will win out.
"the kids who graduated Uni/College and got into the corporate computer and networking world back when computers started becoming ubiquitous on desktops all over the corporate world are now roughly in their mid 50s. ... In their minds (and the generations following) it's supposed to be shoddy code,"
True in a general way but there were still some big systems around and no doubt some of the new graduates became familiar with them. And as you and I both know there was Unix continuing through all that.
It wasn't all flawless in the past. I had one card compilation run that didn't - a new version of the system library had gone in that morning and it wouldn't link. It was reverted the same day, of course.
I believe it is because many of the applications for specific industries (law, teaching, accounting, etc) were written by a lawyer, teacher, accountant, etc to solve an issue they had. They were not trained developers but managed to bodge something together that did the task, but in an appallingly badly written way.
They then think "Aha! I can make money selling this to other lawyers, teachers, accountants, etc" and thus a new shitty application is born that does things like store user information in the program folder or HKLM, or has hard coded paths or does other things that make my blood boil.
Support page for apps like this usually contain items like:
Support FAQ
Q1. Application does not work correctly.
A1. Make everybody an administrator.
Q2. Errors writing to Access/Arcane roll your own format database.
A1. Disable SMB2, enable SMB1 and oplocks.
Q3. Errors writing to SQL Server.
A3. Configure application to connect to database as SA.
And as for SQL, most of these "developers" don't know what an index is and write queries that might work OK for small data sets, but will make performance fall off a cliff at scale as they have never scaled it that far. Had numerous SQL based apps where somebody running a report at head office will lock resources the application uses, so front line staff running the application will get time outs or application crashes while the report runs.
Some of the reasons that lawyers, teachers, accountants, etc wrote their own software were
1. some IT department (either in-house or 3rd party) told them it would take 5 years and umpty squillion quid to write
2. the IT professional didn't understand the business, workflow or what the program was supposed to do and hence it didn't work
3. the requirement wasn't far enough up the business priority list to get anything done
4. it started life as an utterly trivial thing and just grew
Still have the scars from all the above
2. the IT professional didn't understand the business, workflow or what the program was supposed to do and hence it didn't work
2a. The IT professional wanted to understand the business, workflow, and what the program was supposed to do, but some manager told him he didn't need to know and that he should just follow the spec. The spec was written by someone who understood the business but not computers, and couldn't write clearly to save his life, so the program didn't do what anyone expected.
Been there, seen that ...
Thanks for the poll tip. I fear I'll have to use it at some moment.
A second part of the story would be digging in forums to find a solution, with the mandatory "you should get Linux".
And I love the joke. It works not only with consultants, but also with every urbanite coming to the country side.
Yes, I'm embarrassed to admit the joke fell completely flat due to the two halves of my brain disagreeing. It was supposed to read "Linux subsystem for Windows"
I liked it better the way you wrote it, though some commentards seem not to have got the point.
IOW: If you're thinking of using WSL you're approaching the solution inside-out.
Did you ever consider not using Windows? There are two very good alternatives that can do (almost) everything Windows can, and in some ways a lot more. And both can crash, but
And if you have a Windows app that you absolutely have to have, how about setting that up in a virtual machine? Better yet, if the app likes to crash in the manner described in the article, why not freeze a "good" app startup in a VM, and start copies of that and never see the problem again.
> You will probably find a dozen free software projects promising to do the same thing.
Guys, guys! Aren't you losing contact with reality here? If Dabbs is paid to teach people AutoCAD (let's assume), do you really think he can waltz in and tell them he'll show them FreeCAD instead?...
Only a privileged few have the freedom to choose their OS and apps. The vast majority has to do as their boss or the market tells them.
> as a consultant I see it as part of my job to inform clients
That's true, but Dabbs spoke definitely about (I quote): "programs that I am certified to teach", so the situation seems to be slightly different here I guess (although it sound like he's amalgamating several similar though different situations in his article): It does sound like he's supposed to teach a specific software, come hell or high water.
very definetely ten
Do not be tempted to goto 11... bad things happen at 11 such as having a room mate called 'bubba' and not being allowed out of the building you reside in for another 11 years. On the plus side for 11, burning down the software company hq that gave you such shite software in the first place was rather stress relieving. especially the bit where you yelled obscenities for 20 minutes until the police arrested you
Nothing like running live demos or training on a remote server and having it crash/dump in front of everyone's eyes.
Does anyone believe the, "It's never done that before." ?
I've never heard anyone say, "We're not going to buy/use this $100,000s software." So they must, right?
All of it?
I found in order to uninstall that sh*te I first had to upgrade it. Now I'm busy installing it, but I'll run Wireshark for a week to see if it hasn't pooped some spyware in another corner because it is even more chatty and possible date-exporting than Windows itself.
It really is unbelievably crap software.
All of it, but only when opened in front of a class?
It probably can't cope with a projector being plugged in and displays and stuff changing since the last time it was opened so it decides it needs to count the displays again... really... slowly.
Or it doesn't like not having internet.
Or God knows what, it's Adobe.
The next time it happens Dabbsy should say "Excrement! I want you to uninstall Creative Cloud. Uninstall it! All of it!" then his students will be sending on their desks and shouting "Oh Affinity My Affinity!" like in Dead Poets Society. Probably best to do it on retirement day just to be safe.
> Now guess which app launches directly into Not Responding mode every time.
I actually have a couple which do this. They all have in common to handle rather big files (>0.5 GB), to have been initially written 10 years ago in 32-bit Windows times, and to have lots of parts which haven't been since rewritten. So even on a modern multicore 64-bit system, parts of them still chug along on a single thread, using soberly only 2GB of RAM on a 64 GB system...
So you always start the program, go do stuff, and when you're back it's finally ready to accept user input.
Well, what can you do? Those are very specific and unique programs with only some 100-200 users worldwide, so there definitely isn't any alternative option available. As for hiring a bunch of programmers and have them rewrite the whole crap from scratch, budget says "no"...
The whole, ohhh the app looks like it has started immediately, now it's sitting there not responding is just the app doing everything and cleaning the kitchensync as part of it's startup process .
It just throws something at the screen quickly, so that it looks it has started
And then it goes off and does silly shit like looking online for an update, using a webaddress that is no longer valid (but the fix for that is in the update ), trying to make a rolling snapshot of it's internal database
having a quiet laugh at the contents of your Pictures folder
reading your email, and replying to 5 random of them
and all the while forgetting to send a sign of life to windows, so that the app literally is not responding .
We used to have splash screens for that
Going off and doing silly stuff like looking for a non-existent address would be a harmless pastime except that most code is still written with busy/wait loops, its just too difficult to spawn a thread to manage this and get it to wait for events and stuff. This should be routine OS work but trying to do anything like this in Windows is esoteric (especially since Microsoft dumped POSIX for something that's obviously better if you could just get it work properly).
I think this is why muilticore processors are now so popular. If you've got four cores then you can run three crap programs or threads on it and still have a semblance of a working system.
My work life has been built around embedded systems so I don't get to write this sort of crap. However, the products that I have built often have a handy little Windows application for configuration and monitoring. This is where busy/wait comes to the fore. Its also the home of the home-made serial protocol and applications programmers that always take ages to do anything and can't debug their code (its obviously the firmware unless proven otherwise). These programs get bigger and bigger but are never completely debugged -- there's always a new version with updated GUI -- same bugs, of course -- and performance that's heavily dependent on how fast you can serve polled data to them.
Am I glad I'm now retired.......
It just throws something at the screen quickly, so that it looks it has started
And then it goes off and does silly shit...
Yes, but a well written ... well, any competently written ... application would do the silly shit in the background while leaving a responsive GUI thread running in the foreground telling the user what silly shit was going on, or just displaying some hints and tips, or a message of the day.
As long as the GUI thread was processing input messages it would stop the OS thinking it had stopped responding.
This stuff is not rocket science!
> Yes, but a well written ... well, any competently written ... application
No point reading past that, since we'd be smack in the middle of La-La Land... The more realistic description would be of a quick-and-dirty application released as soon as most of the features are "stable enough" with the promise that the next patch will fix everything...
/s
I don't recall ever having been in a [meeting, presentation], where the person at the podium did not have to spend 10 minutes playing with the hardware.
One assumes (because I always do) that they had it all set up and running before the punters were let into the room. Makes no difference, when the audience arrives, either Windows or the software will go on break. The screensaver will time out (even though you set it not to), and/or Adobe Acrobat will invariably choose this moment to pop up its full screen advisory that there is an update available and would you like to install it?
And, if the screensaver times out or the laptop goes into sleep mode (even though you have this disabled when on AC power...you did plug it in?), the projector will now notice that there's no input, and display that fact, along with its splash screen, so you have to play games to even get an image up on the screen again.
Never have seen it work any other way.
"Its perpetrators should be taken out behind the barn and shot, for the good of humanity."
On the other side of the coin, much of humanity has demonstrated over many years that it is incapable of applying OS and other updates even when prompted to do so. They lead such busy lives, dontcha know :-)
"No matter that I am the meeting host, I'll just restart my computer, shall I?"
Two laptops, one as host and the other as presenter. Since you already know it's going to be not responding at some point, this also works around the issue of lack of resources on the host's computer.
We had a guest speaker the other week coming to give a presentation. He'd alarmed us by saying he had two videos to show which were currently on his phone. Eventually he got them into his .ppt which he sent in advance. Our Mac colleague couldn't get them to play. He sent me a copy. It turned out they were some Microsoft format.
LO on my main laptop (Linux of course) would play them but they both insisted on playing twice. Fortunately VCL transcoded them to mp4 (at a fraction of the former file size) which played OK, including playing sound to external speakers, so I swapped them for the original versions and saved as an Impress file. I took my laptop along to the talk just in case.
As it turned out the speaker brought his own laptop - I didn't look too closely but I think it may also have been a Mac - so they decided to use that. His laptop couldn't get sound out to a set of external speakers. These decisions were made while I was busy sorting out the presenter's mic. The situation was salvaged by borrowing a very tinny and not very powerful Bluetooth speaker.
Presentations on customer site are almost always a nightmare. It's always the wrong cable for the screen, or the laptop doesn't sync, or the feed is not recognized, etc, etc.
You get there a full hour before the meeting, and 5 minutes before H-hour, it's still not working. The IT/helpdesk jockey is still running around verifying this and that, and you're watching people coming in with their coffee, smartphone and laptop, already bored and wondering when it will be over.
Honey, it hasn't even begun to start.
The only times I have ever had a presentation go off without a hitch is when all I had to do was bring a PDF on a USB key - all the hardware was preconfigured and supplied by the customer. In that case, you go to the room with the helldesk sacrifice, hand him the USB key and wait for him appease the gods so that your PDF can be displayed. Generally, that goes rather well.
My presentations generally do not actually require slides, I merely use them to keep me on track (they contain at most a single sentence, usually even just a few words) as I tend to present from what's in my head - that's far more natural than reading from paper or slides and you keep connected with your audience.
It's only when you have to show architecture or numbers that a slide is really needed, and I think numbers belong in reports, not in a presentation. I'm kinda old school that way.
The aforementioned old school also means I can present if all equipment fails. As long as I have my cue cards and enough light to read them I'll be fine. That is, of course, not possible for everyone but for my work it's not a major issue. I suspect that's the main reason why I rarely have any real equipment issues - the gear probably senses that failure would not affect me much .
Notable exception: sound. I can project my voice quite far, but I find it exhausting so I prefer to be properly miked up (and know where the mute button is). Most of the time I bring my own gear and that offers 3.5mm, XLR and USB-C digital out so there's usually at least one way to get that to work :).
These days I'm looking at it from the other side.
Generally we find that our speakers will provide PPT or maybe ODP on a key and we can provide a laptop, projector and, if necessary loudspeakers. But then, as in this case, somebody says they want to play video, with sound, from their phone...
Although a Mac tends to be easier than Windows at managing sound, it's not perfect. I now have SoundSource from Rogue Amoeba running on all machines, and that makes it all a bit more logical.
I liked their software so much I licensed all of it, and that hasn't happened to me since Serif's Affinity.
Dabbs probably knows this already, but in the French version of this joke the Management Consultant is an Enarque, which is to say a graduate of the Ecole Normale d'Administration.
-A.
Why not have one laptop which is the host of the online meeting, and a second one on which the application is running? Then you can do what you like on the application running laptop, restart the app, reboot, whatever, whilst maintaining meeting control from the other one. When the application is behaving itself, grant that laptop presentation rights.
Come to think of it, that clifftop Himalayan monastery does sound rather appealing right now...
I would guess that your app is calling back to the mothership to check if you are up to date on your subscription.
Find that domain and send it to 127.0.0.1 in your hosts file which should cause that lookup to fail and all will be good - up until the cached "offline" mode requests and requires a connection to recheck your status, and you don't remember wtf you did and end up reinstalling windows after 4 hours of troubleshooting!
Back in the late 90's or early 2000's, I had a particular issue I couldn't resolve... I went searching for answers and found nothing, not one single person describing anything remotely similar to what I was experiencing. I did something to resolve or work around it... or simply switched to an alternative.
Fast forward about 10yrs... different operating system, similar type of issue and of course I'd forgotten exactly what I'd done to resolve or work around the problem all those years ago... went searching for a solution and found nothing.... Except for the question I'd been asking 10yrs earlier... that I'd never had an answer too.
It's now 2022... and to this day. It's been so long that I can't remember what the issue was, what the software/hardware was and of course... what I did to resolve/work around it.