I know I’ve mentioned this before, but the American mania for complicating processes and systems that are just fine as they are is a cultural sickness. It is also obviously unethical under the category of irresponsibility, with a dash of arrogance. It is an American mania.
Herman Kahn used to tell the story about how American jet fighters were equipped with multi-million dollar systems to prevent the aircraft from stalling, triggering alarms and lights and other automated reactions. “The Soviet equivalent was a little dial that had an arrow that went into a red zone,” he said,”and the whole system costs about five bucks. It works just as well as ours.”
Right now, I am struggling to write blog posts because the WordPress “upgrade” has become mandatory, and the thing is infuriatingly complicated and clumsy. Naturally, the company’s “explanation” of how to use it is also incompetent, using terms without defining them, telling me how easy and versatile the new system is while ensuring that it is neither by inflicting instructions that will take me hours and hours to absorb and master, if I ever can.
In one of many recent online chats with WordPress customer service agents, I was asking how I could stop having to repeatedly select the same “block” (this jargon means, I finally figured out, one of I-don’t-know-how-many shiny new packages of composition and format features a section of text could be managed with) I wanted to use, and just have a permanent, familiar formatting system for all posts, all the time—you know, like I used to have before WordPress gave me all these floating options I don’t want or need.
The answer? No! The new way was better, see, because I could shift into a new package mid post! But I don’t want or need to shift anything mid-post, and this “improvement” is costing me time and causing frustration. Frankly, it’s making me want to chuck the whole blog.
Here’s a perfect example of the unethical tech mindset at work. The “classic block,” which is essentially what I have been using for ten years here, has an icon to allow me to hyperlink a word to a web address. It looks like two links in a chain. The default “block,” however, which keeps replacing the “classic block” as I write, appeared to have no linking option among its features. “Oh no, it does!” the helpful tech agent explained, and quickly sent a little animated video with moving red arrows showing me how to hyperlink text in that “block.” The source of my confusion was that that block used a different graphic symbol for a link!
That block uses what looks right and left parentheses symbols with a minus symbol in-between.
“Why the hell did WordPress do that?” I typed back in all caps. Why? What is the point? To be cool? Screw “cool,” I want clear, please. How am I supposed to know that the exact same function in different blocks will have a different symbol? Is taht supposed to be a game? Guess the symbol? How can that gratuitous extra step constitute an improvement? What sadistic tech nerd thought it was and was allowed to install such an obviously useless and confounding feature? There is no possible justification for doing that, and WordPress’s incompetent decision cost me almost an hour of frustration and wasted time that I will want back on my deathbed.
It’s not just WordPress, of course. The same is true of the keyless ignition system in my car: after a full year, I still have to pause and think every time I turn off the vehicle, “push button without my foot on the brake,” unlike the way I start the car, pushing the button WITH my foot on the break. Why is this deemed an improvement over “turn key to the right for “Go” and to the left for “Off”? It isn’t! Some smart aleck jerk just thought it would be cool not to have to turn a key.
The same is true of the nifty high tech elevators that you have to program in the lobby, and then a little light and map on the panel tells you which elevator will take you to your floor. What could have possibly been more simple and efficient than “get into elevator, push button with desired floor on it, ride to desired floor, get off”? What deficiency did the new, high-tech “improvement” address?
None. NONE! The change just amused and empowered arrogant engineers and programmers who changed a perfectly good system that everyone was familiar with and had mastered because they could, without any consideration for the effect on the people who use the system.
It’s just a tiny added factor among the many accumulated one that make people snap, become drunks or sink into depression, but it is an added factor, and and even one more is too much.
Ethics Alarms 
This post took me 20 minutes longer to make than under the previous, apparently inadequate system.
Why you ask? Among other reasons, all of the features that once were just there on the page had to be summoned via a drop down menu, searched for, and clicked on. This adds processes and time, and if someone can explain what the added clicks accomplish, I’ll send them a ham.
Job security for programmers. If they did it right the first time, they’d have to find other jobs. “Fixing” stuff keeps them employed and allows WordPress to drop the “new and improved!” label on the product. Win for everyone except the customers.
New Coke.
I admit the mandatory shiny baubles are successful. It has successfully impeded quick and easy updates to my blog. Anytime meaningless so-called ‘improvements’ require too much time to do the same tasks, I look for a different platform. It does mean I have multiple dead blogs in my wake, but my time is valuable too and I don’t get paid to keep up with their short attention span. They always want to ‘explain’ UI changes for ‘security’ or ‘interoperability,’ but I worked in software development and that’s really code for management and marketers, not developers and usability testers who are told to shut up and make it so.
Some third-party hosters have their own simpler UI that feeds files into the WordPress zoo, making the time-wasting professional mavins irrelevant. I just can’t afford add-ons these days.
I don’t know of any major site that doesn’t make these anti-usability changes that busy professionals or family members can’t spend the time to keep up with. The changes are to try to excite the young and easily bored younger people who have too much free time, I believe. You know, those who won’t spend money or edit voice input. (I have seen too much fiction where the ‘writer’ apparently doesn’t know about homonyms in their fiction) If the companies wanted cash flow they’d keep changes minimal to keep it easy for those with limited time. Tumblr lost my posting a couple of years ago after similar changes, and I heard they were sold recently as if for a fire sale.
I did not care, because I don’t have the time to chase butterflies.
” Why is this deemed an improvement over “turn key to the right for “Go” and to the left for “Off”? It isn’t! Some smart aleck jerk just thought it would be cool not to have to turn a key.be cool not to have to turn a key.”
It also makes you pay $400.00 to the dealer if you lose the fob that allows the car to start instead of $1.99 for a spare key from Home Depot.
And god forbid the battery in your key goes dead. Then you have a very expensive boat anchor until you replace it.
Also, as I learned to my misfortune, it make you pay $400 if you drop the key and it shatters like glass when it hits the floor.
You mean as opposed to $250 that I believe it costs for a new key/fob for my car that still is a key you put into the ignition and turn.
My previous car — which was a 2003 — I could go to Home Depot and get new keys for maybe $20 or $30 dollars. Now, with a 2004 model, I have to go to the dealer to get a new key and take out a second loan on the car to do so.
Since we bought the car used and it only came with one key — we have had to be very, very careful over the years to not lose or break that key. What progress!
“I kind of like my keyless ignition button on my VW GTI,” he said sheepishly.
The key just stays in my pocket. The deal dealer replaced the battery at no charge when it started to go bad and the remedy was to hold the key right next to the steering column. The only behavioral oddity I’ve encountered is I’ll occasionally turn the engine off, and then, forgetting I’ve done so, I’ll push the button again, thus RE-starting the engine. Which I realize well before exiting the car.
When I was in high school (in the ’60s, not the ’30s) I had the fun of owning a 1930 Model A Ford Sedan (with suicide doors). You put your key in the ignition switch, pulled the choke, retarded the spark, then stepped on the little button-like pedal on the floor board that ran directly to the switch on the massive starter bolted onto the flywheel housing just on the other side of the plywood fire wall (so called). So, I guess pushing something takes me back to … Wait! The ’60s? Yikes!
“Some smart aleck jerk just thought it would be cool not to have to turn a key.”
Apparently, that same smart aleck jerk thought it would be cool to start the car without turning a key, as, for example, when you are in very hot or very cold weather and you remote start your car as you leave the restaurant and have it closer to the desired inside temperature as you get into the car.
And, the same or another smart aleck thought it would be cool if, loaded with packages, you could open your trunk or liftgate without fumbling through your man-purse to find your key while dropping one or more packages.
And, someone also thought it would be cool if you had your baby in one arm and your briefcase in the other, that the car doors would lock automatically as you walked away from the car. (You can close the door with your hip, but, try locking it that way.)
Keyless fobs also make it more difficult to lock your ‘keys’ in the car, so, you won’t have to remove the license plate to get that key you secreted behind the plate.
And, yes, there are cons.
As to Wordsmith, I have no opinion because, thankfully, the pain seems to be fore the blog creator and not those who merely post comments.
My wife’s Yukon has factory installed remote start and still has a key. It’s got a separate button on the key fob. Pressing it locks the doors if they are not, and starts the engine. When you get in, you put the key in and turn it on. If you touch any controls before turning the key on, it will kill the engine. This addresses the concern of someone jumping in and trying to steal it.
She previously had a dodge caravan, also with a regular key ignition. It had buttons for each side slider and the rear hatch.
I’m related to one of the inventors of the keyless trunk/lift gate. After she told me about it the first thing I asked was, “doesn’t that make it easier for a would-be kidnapper to shove you inside?” She said she never thought of that.
Neither did I. Now I know I can use my car for kidnappings. I need a new profit center…
I’m not sure it would make it easier — once the trunk is open, doesn’t matter how it got opened. And I don’t think the would-be kidnapper could open it with that foot kick unless she already had the fob.
Upon further review, if the kidnapper was the car owner, then, yes it would be easier. Thanks be to Jack for steering my mind in that direction. 😉
I am beginning to understand why you did not dedicate entire blog posts on certain current events, like Donald Trump downplaying COVID-19 in January.
Or Part 2 of the Difficult Ethics Conflict regarding the pandemic.
I’ve posted on they keyless ignition systems before, they cost lives.
It is far easier to accidentally leave the car running and has caused many fatalities when it is in a closed, attached garage.
They keyless ignition was also implicated in runaway Toyota cars, costing them billions in settlements. Holding the off button for five seconds is far less intuitive than turning off a key.
One of the drivers behind this is the problems brought by a key in the steering column with interlock on the gear and steering. That design was brought about by government anti-theft regulations. With modern key or fob interlocks and engines incapable of running without a computer, they are obsolete, and no longer regulatory mandate.
They key could have gone back to the dash. Or it could have been replaced with a rotary selector that is intuitive. Retain the traditional off-acc-on-start pattern. It is clear and much less prone to error in controlling a potential dangerous machine.
Here’s Johnny thinks the deaths are worth it so he can more easily get his trunk open when he’s carrying groceries.
Ok, that was unduly harsh, but the point is fair. I’m thinking about a new rationalization called “The Silver Lining Appeal.”
I don’t see it as unreasonably unfair. My criticism of the current implementation of keyless ignition is unrelated to these extra features. The new functions can be done with a key or without a key. It’s the implementation of one button that deserves derision.
The established paradigm of selection of engine on, engine off, accessory on, and accessory off was thrown out the window without a good reason. The new implementation is less obvious and less intuitive, and most of all wasn’t necessary. Picking one, single button, plus an unrelated control, the brake, to make many selections is not a good user interface design. On, accessory and off should be separate buttons, or a rotary selector. It is as stupid as a button to cycle through the different wiper settings, or exterior lighting. There is a reason we have the multiple controls in a car, it is that we activate them without looking and by muscle memory.
I think there is regulation coming. Some cars have buried selections in a menu structure. A common one is adjustment of the HVAC settings. We’ve attacked distracted driving due to cell phones. Making controls non-intuitive is just as bad.
I don’t believe I advocated for or against keyless.
I do advocate for carbon monoxide detectors in every home and for situational awareness. Where both of those are lacking, there are personal injury lawyers who can direct the blame away from the injured person and toward the responsible party (I almost said toward the party with a lot of money, but that would have been wrong).
It’s a simple matter to program keyless ignition cars to shut themselves off after idling for a while, and I think a lot of them do that nowadays. Of course, an override is necessary for those who want to keep it idling for an extended period for heating or cooling while they leave a pet in the car or perhaps take a long nap.
It’s also simple to have the car sound or flash alerts if the car is left running while the driver walks away, and I think a lot of them do that.
But, beeps and whistles and flashing lights can be annoying, and the real problem is not the ignition system but the fact that modern cars are just too darn quiet. That’s why people leave them running in a garage and why joggers nearly get run over – they can’t hear the car.
I think the best hope in reining in this behavior is in the giant corporations. The IT folks have to know that these types of changes are very expensive in employee productivity hits. Obviously updates are vital to patch security vulnerabilities. New features can boost long term productivity. But wholesale UI changes that send the workforce into training are pointless and expensive. When corporations are sensitive to the bottom line, they should be proactive at making it clear that a stable user experience is a key criteria for keeping your customer.
I’m not sure that there is an addiction to complicated processes in America. Indeed most business that succeed do so by reducing complexity, so in general new systems will almost always reduce complexity. There is lag time after adoption though. I work for an enterpirse software company that recently changed one of it’s features. The new feature was much simpler. Two button clicks where it used to take 5. Did the same function faster and simpler, but our client base hated the change. It was too different. Doesn’t matter that it was better. We literally added two fake buttons that were closer to the old style and every couple quarters the game plan is to remove them. Let the pot rise to a boil instead of tossing the frog into a boiling pot as it were.
Your Russian story reminded me of another apocryphal example. It goes something like this:
For their space program, American’s designed a special pressurized ballpoint pen that could write in zero gravity, survive the huge g-force of a launch without leaking, and leave ink dry to the touch near instantly without harmful off gassing anything too dangerous in a confined space. The total cost of the program was well over $1 million in 1970s money. What did the Russians do? They brought a pencil.
The broad strokes are true. We did design a special pen, it didn’t us anywhere near a million. The Russians did use a pencil and to be fair we thought about doing the exact same thing. Pencil lead though is made of a very conductive material and it isn’t good for the lining of your lungs. A little graphite in the wrong place and primitive circuits of the time might short in a bad way, not to mention the near certainty of breathing it in that near coffin like zero-g environment. All in all, I think they made the right engineering trade off. Front load a low risk complexity instead of late-game high risk simplicity.
Re: WordPress. User Experience (UX) is hard. My first job out of college was centered on UX, and you need people who know about it to get it right. But they’re expensive, so I bet WordPress does not have the best, if any.
Re: Elevators. It sort of makes sense in very tall buildings duri g rush hour. You know how it was fixed in the past? By having elevators go to set of fixed floors during certain hours. No need to come up with fancy system that users have to learn.
Forty years ago, I interviewed for a job at IBM and one of the questions was, “What would be the best way to program an elevator for times of peak usage?” I rambled for a while about using linear programming to minimize waiting time. When I was done, the interviewer said, “For that to work, the program would need to know what floor the passengers were on and what floor they were going to before it sends the elevator. But the program only knows the floor they’re on. It doesn’t know where they’re going until they get in.” For some reason, the solution to that problem never occurred to me until decades later when I first saw one of the nifty high-tech elevator that Jack hates, and then I felt really dumb for not thinking of something so obvious.
I feel your pain, Jack. I remember when SB Nation was on the blogging platform “Scoop”, which still has a website calling itself a “collaborative media application,” and the big innovation for that platform was that it allowed user content in the form of “diaries,” which encouraged user interaction and had the additional benefit of showing off the work of talented writers who didn’t have a home (with the side benefit of identifying people who might eventually become front-page authors for the site).
Eventually, SB Nation got wads of cash thrown at them, so they developed their own platform called “Chorus” which was supposed to be a massive improvement, but to me, it wound up being far harder to use than the platform I had become used to over years. It had some of the same problems you describe in your post — what used to be easy was now a multi-step process. But it was visual (WYSIWYG). by God, and permitted a ton of formatting and shiny new content options, so it was therefore much better. Umm… not so much.
Anyway, through much effort I found kludges and work-arounds to the more annoying problems, leading me to use Markdown to write the content, then render it as HTML and paste it into the application. It was easier, more efficient, and far less resource-intensive even if it required a couple more steps to do. But I am a computer person, so that makes such solutions much easier to achieve than an average user, who would be frustrated and confounded by both the problem and the possible solutions. I suspect this is where you find yourself.
How we somehow decided that complexity was a desirable end in itself, I do not know. I suspect it has something to do with the obsession computer people do with creating an “idiot-proof” system, a shiny new interface that looks sexy, or a desire to solve a simple problem that, due to its nature, requires a complex and often opaque solution. Sometimes, people become so obsessed with slaying the metaphorical dragon that they never stop and think whether or not it actually needs to be slain, and what problems are solved by its demise that couldn’t be solved more simply.
This reminds me of a wonderful Jack Vance novella, called “Dodkin’s Job,” which is a dystopian view of what happens when organization and its subsequent supporting bureaucracy becomes an end in itself. Anyone who hasn’t read it should locate a copy and spend the half-hour or so it takes to read. It is appropos not only to this situation, but to our government as well.
You are blaming the wrong people. I am a software engineer, and I promise you it is not me or other programmers who decide to add ridiculous complexity to the UI/UX. Those decisions are made by either a UI designer, or a business person. As a software engineer, I try to push back on stuff like what you are describing, but I get paid to write code, not second guess the business. 99% of the time no one is going to listen when the software engineer tells them what they want is a bad idea (or just plain stupid).
The UI being different in different places probably indicates that features were requested willy nilly throughout the development process, and added at different times, by different people, and possibly designed by different UI designers , assuming there was a UI designer at all. Many times there is just a business person requesting features, and a bunch of software engineers carrying out those requests.
If there is no UI designer, that makes the programmer the UI designer, and we are not trained to design software interfaces. We are trained to write code. Some of us are better than others when it comes to considering UI/UX, but pretty much none of us have actually been taught how to formally create uniform, easy to use, aesthetically pleasing software interfaces.
Additionally, when you add features willy nilly like this, you end up with spaghetti code unless there is a lead developer overseeing what everyone is doing. Generally speaking, there is usually no one person designated to do that. The bigger the software engineering team is, and the more parts of the code are outsourced to cheaper contractors, the less likely it is that there is someone keeping track of what everyone is doing. What ends up happening is the same code is duplicated in multiple places in the code base and used at random in different places by different people, which results in the same feature being different in different places.
What I am trying to say is that we don’t do it on purpose because we are evil, cynical smartasses. Software engineering is complicated, and at the mercy of non-software engineers who like to order us to do stupid things.
I love your blog, by the way. It makes me think about the underlying logic of ethics in ways I normally wouldn’t.
Great and useful comment even without the compliment.(Thanks.) Comment of the Day.
I went to school to learn programming/computer science but when I actually got into business I went over to the dark side and became a user.
What I eventually found is that the IT developers and coders need a translator between them and the end users because they just don’t think the same way. Not only that, but end users tend not to be able to articulate what they actually want in a way that IT folks can understand — more than once I saw a process where it went: “That’s not what I want. Well, that is what you said you wanted. Well, yes, but it’s not what I needed.” Frustrating all around.
My inventory control group ended up establishing some credibility with the IT group basically by finding bugs in the systems, proving that these bugs existed (by figuring out how to reproduce them), and then getting the IT people to understand that. We then were able to figure out systems that we needed and sit down with the other side and actually communicate our needs in a way they could understand.
That sounds sort of easy — but it was tremendously hard, and I suspect just doesn’t happen very often.
Hence, the things Jack describes. There aren’t evil, diabolical people but there are different groups of people who think differently and it’s tough to establish meaningful communications.
It is very true that end users often say they want something when that isn’t really what they want. Adding a middleman is not the solution I prefer to employ to solve this, however, as it often just turns the process into a giant game of telephone, with additional places for misunderstanding to be introduced.
The best way to solve this problem is to create prototypes, either using design software or with simple, throwaway code, and actually show it to the end user requesting the feature. Take feedback, redesign your prototype until the end user agrees it is what they want, and only after that agreement is reached, implement the feature. This process is called focus testing or user testing, and in my experience produces the best result.
Can’t argue with that. In my case, the ‘middleman’ was actually the end user so we sort of adopted the same type of solution that you’re recommending. It was just that we had to establish our credibility before they’d listen to us — too many previous instances of users making mistakes and calling that a ‘bug’. We gave them solid evidence for the bugs we did find, and that made them receptive to our input going forward.
Dealing with bug reports is a skill that not all programmers have mastered. Bugs that are “not actually bugs” are always going to be reported. How you define “not a bug” is the issue.
Sometimes bug reports are made for uncontrollable reasons, such as differences in browsers. For example, a programmer working on a web page cannot do anything about things like differences in how scroll bars are rendered in safari and chrome. These are differences in the browser, not the web page. So those are “not going to fix” bugs.
Other types of bug reports, such as user errors, can be more complicated to deal with. An ethical programmer will recognize that frequently reported bugs that are actually caused by user error occur because the software interface is confusing. Confusing UI, is, in fact, a bug. It should be fixed. The software might be working as intended, but the “as intended” behavior is confusing, bad, and therefore a bug.
It is a skill to listen to what people are saying, why they are saying it, and determine what should happen correctly.
There are a lot of other issues that happen in software engineering that also affect dealing with bugs.
Some programmers take all bug reports as an insult to their own programming skills. Those programmers are not the programmers who should be assigned to deal with bug reports. It takes a person willing to acknowledge their own mistakes, or the mistakes of their team, to adequately deal with these types of bug reports. Many people are not emotionally capable of this behavior. They get defensive.
The personal ego problems aside, the field of software engineering has its own special ethics issues.
Depending on the professional environment created by the business, there can be real consequences for acknowledging UI problems. The business often does not want to hear that the software they paid lots of money to produce has problems, and needs to be fixed. Even if it is not the fault of the programmer, who did exactly what they were told to do, there could be consequences for acknowledging UI/UX problems. Especially if the software engineers in question is a contractor who has no protection from getting fired at any time for any reason.
In the software engineering profession, most software engineers are going to be contractors. Some of them are very technically proficient, very expensive contractors. Some of them are very junior, very improficient, very cheap contractors. Both types have no protection from losing their current position for any reason at any time.
I see very few people in the middle position of being mediocre, but I’m sure there are a portion that fall in this category as well. They just don’t tend to stay there, ending up in either the proficient or improficient category fairly quickly.
Very proficient contractors are outnumbered by very improficient contractors by a very large ratio.
The minority of software engineers are employees, who are basically never going to be fired for any reason.
Becoming a contractor when you are very technically proficient is fairly easy. Becoming a contractor when you are very improficient is a lot more difficult. Becoming an employee, regardless of proficiency is extremely, extremely difficult, and highly sought after.
Contractors want to be employees, and are in constant competition with each other and with employees to prove their worth. Employees can do whatever they want, blame whoever they want, and get away with it because most businesses don’t want to deal with the liability issues that come with firing an employee.
This creates an imbalance in power between employees and contractors, which contributes to an environment of generally not acknowledging errors unless you absolutely have to. So bug reports get spit back as “not a bug” until someone with employee status or very proficient technical skills, as well as no ego problems, and a personality that makes them impervious to the shunning of their peers and the disapproval of the business, acknowledges them.
There aren’t very many people like that.
So mostly bug reports get spit back as not a bug, unless there is some assurance that there will be no repercussions for doing so.
It sounds like you created such an environment.
The most unstable shops I worked in had marketers doing that middleman interaction and promising impossible things outward and then made the gnomes in development kludge up anything even if it didn’t work.
It is very true that end users often say they want something when that isn’t really what they want.
Excellent point. The users have a problem or an annoyance with how the system works, and often they think that these are some kind of deliberate omission or poorly-conceived design costing them precious time and effort.
As often as not, I find out the problems aren’t really problems, but built-in safeguards to prevent users from corrupting or kludging up the system by taking convenient shortcuts or failing to complete steps necessary to make the overall software application work correctly. Sometimes these problems can be streamlined, but often, users simply hate putting in required information that makes them perform extra movements/keystrokes in order to make their information input useful.
For example, very often users will fail to fill out fields they don’t have the data for right at hand, promising themselves they will come back and do it later. The software developer or business process manager, knowing the input will be confusing or useless if certain information isn’t entered, makes certain fields required which forces the user to make sure he has everything before completing the step. The user complains about this, and software business people go about trying to “solve” a problem that will ultimately make the software less useful or even potentially destructive to the business processes the software is intended to support.
Most of the time, an explanation of why the step is required is all it takes. Too often, that becomes too much to ask. As often as not, people are trying to “solve” problems that should not be solved, because they aren’t actually problems.
There are people employed at companies, making a lot of money, whose job is to ‘improve’ things. If they say ‘it works pretty well as it is’, they don’t have a job. When I worked at McDonald’s, this was very evident. McDonald’s at that time worked quite well. Every 6 months or so, the Corporation would introduce an ‘improvement’. These ‘improvements’ usually required an additional worker or two just to sell food at the same rate as before the ‘improvement’. My store was a franchise, and the owner hated these ‘improvements’ because they made the food worse or the process slower. Many of these changes were geared towards slow stores, that didn’t sell product quickly. Most food at that time was discarded if it didn’t sell in 10 minutes. This isn’t a problem if you are cooking as fast as a 60 A 220 line can feed the grill, but it is if you have a store in the middle of nowhere. These changes were things like warmers that could hold the food for 30 minutes before it had to be made into a sandwich which could then be held for 10 minutes. Well taking food off the grill, putting it in a warmer, taking it out of the warmer, then making a sandwich is much slower than just making a sandwich right off the grill. Other changes made the grill area geared towards making 1-4 sandwiches at a time instead of 6-12 at a time. My owner fought these changes, realized that he couldn’t win, and sold his 5 stores to the Corporation for $10 million. The corporation then sued him because their ‘experts’ using ‘improved’ techniques were not making a profit on the stores while he made $5-$10 million each year in profit from them. So, if you are frustrated by how slow McDonald’s is not, you can thank the ‘experts’.
I know the pain of hard-to-use software. Back about 1990 my county government joined two municipalities in our county to form a combined 911 Communications District for Fire, EMS and Law Enforcement. This process included purchasing a CAD system and a common Records Management System for all agencies. Long story short, the vendor who got the bid promised the moon and stars to the 911 Board but was barely able to make their product work. The Fire RMS module existed only in demo form and wasn’t workable for over a year. The company promised complete data migration from the systems it replaced. That never happened. Periodically (every six months or so) we would get an “update” that would manage to rearrange familiar data fields, change existing operating steps and relocate data within the system. When we would inquire as to why a feature or function was changed, we would be told, “Someone [never named] at the annual training conference requested it.” (The annual training conference hosted by the software company cost over $1,500 per attendee and was basically unaffordable for us.) Telephone and email follow-up on questions and complaints was slow and minimal. Fixing one problem often caused another. Turnover at the company was high, and we would routinely be told, “The engineer / programmer who wrote that module is no longer with the company,” We all cursed the system just about daily. When it was working, it worked well, but users faced continual frustration. The District struggled on with this system for 25 years, kept onboard mainly by an excellent CAD program, a low cost maintenance / update contract (and sunk costs). County IT staff often found work-arounds in the software that kept our users relatively sane. In 2019 (five years after I retired) , the software company announced it was rolling out a brand new product and would no longer service the older one. Their new product and accompanying maintenance contracts were reportedly going to be very expensive. The District went through a new purchasing process and I am told they chose a different vendor’s product that is working well, at least so far. I’m so glad it is no longer my concern.
At one point I had a car that automatically unlocked the doors when you turned it off. My verdict is that it is a monumentally stupid security risk that someone had to actively design and install, all for the sake of hypothetical drivers who are too lazy to push a button to unlock the doors. Apparently nobody who drives such a car is expected to be in a bad neighborhood, ever.
As far as software goes, I’ve seen system migrations where the new system doesn’t even support vital parameters from the old system, and that’s just the start. Before fixing critical problems, they build new features which themselves don’t work and only cause problems. Basic edits and reporting aren’t available for months. It’s the least efficient way to do things. This is what trough performance looks like.
And STILL there isn’t a universally standard sarcasm font!
You’ve got upper case; what MORE do you need?
Jack, you have all my deepest, widest, most technophobic sympathies. Hurry up and learn the new system before the next update comes along.