Machine Design
Automation Software Is Rude, Offensive, and Impolite

Automation Software Is Rude, Offensive, and Impolite

John S. Rinaldi is president of Real Time Automation

This is a manifesto. I’ve always wanted to write a manifesto. Not a political one like Timothy McVeigh’s or Ted Kaczynski’s, but one that is about something I really care about. Something like improperly spaced pepperoni. Doesn’t it just bug the hell out of you to open the box and see the pepperoni randomly scattered across your pizza? Some slices get none while others get three or more. I hate that.

I’d also like to write a shoelace manifesto. What’s the story behind why my shoelaces are twice as long as the length required for the shoes bought with them? Are they supposed to be user-configurable? Am I supposed to cut them to length? I’d understand if I purchased the shoelaces separate from the shoes, but I bought them as a set. Why can’t the shoelace length match the number of holes in my shoe?

These are both important and weighty topics, but I’m choosing today to avoid these serious and controversial issues to talk about software. Computer software in general, and automation software in particular. At the risk of offending many of my programmer friends in the automation industry, I have to tell you that I find much of the general-purpose software and automation software you write to be rude, offensive, impolite, and insensitive. I spend a lot of my day fighting with it, having to learn about it, memorizing its peculiarities, and hoping and praying that I can cajole it into accomplishing the tasks I need its help to do.

I recently bought a camera. A very impressive Canon that can do both stills and video, which was all I really wanted it to do. But – of course – it has 9,000 other features. It can add music to my videos. It can color and decorate my snapshots. It can wirelessly send my pictures right to Facebook (that makes me shudder) and a million other geeky things that only a photography fanatic could appreciate.

So I opened the box, charged it up, and thought I’d just take a picture and send it to my computer. It took a few minutes, but I figured out how to take a picture. What I couldn’t figure out was how to preview it on the little display, let alone send it to my computer. Seemed like an obvious next step to me, but not to the camera’s programmers.

But I persevered. My (brand-new) mantra sustained me: “I’m not going to let the programmers at Canon beat me.” Four weeks later, hours upon hours of late nights digesting the 186-page manual and some very bad coffee did it. I took a picture and transferred it to my computer. All you women who complain about childbirth should try understanding my Canon! That’s real pain.

Unfortunately, that’s not unusual. Windows and Windows applications are loaded with this kind of insanity. Cursors that randomly disappear (are they on break?), icons that won’t stay where I put them, taskbars loaded with things I not only won’t use, but can’t even identify. Don’t get me started on the obscure messages like “Your Trust Relationship Can’t Be Established.” Doesn’t tell me what that means, what to do about it, or if there is any way around it. I have to expend the effort to figure out a next step, because the people paid to do it couldn’t be bothered.

A few weeks ago I tried to use a new survey tool. I entered all the questions using the disorganized and awkward entry process and previewed the survey. The preview looked great, so I sent it out. Little did I know that the “preview” they showed me was what it would look like if I purchased the annual membership (which I hadn’t). That preview was beyond misleading, more than deceitful: it was an outright lie. It was a sales pitch disguised as a preview.

I have similar issues with my iPhone. Every time I turn it on, it wants me to connect to the Apple iCloud, and when I cancel out of that, it bothers me about connecting to some music service. It refuses to let me control what I do with my device. It forces me through its dialog boxes to be subservient to its desires, not mine. I could, if I spent a few hours working at it, disable these messages, but why should I have to expend effort to make it conform to how I want to work? It should notice that I have powered the thing up 500 times and answered NO to those useless questions every time. If it were polite, it would stop asking.

The automation industry is not a bastion of politeness either. It may be even worse. We expect our users to understand all sorts of arcane terms, force them to configure things they don’t understand or really care about, and give them as little information as possible. A while back I had two Modbus temperature sensors on our test panel. I thought it would be cool to display those temperatures on a small display, so I purchased this little industrial device from an automation company that you all know. I naively thought that, since I speak Modbus more fluently than English, this would be a 15-minute project. If only. Half a day, two days, a week, and the longer I went, the more time I wanted to put into not losing what I’d already invested. Finally, after two weeks, five calls to technical support, and detailed study (and more bad coffee) of their 125-page manual, I surrendered. Their programmers had beaten me into submission. Displaying two Modbus registers on the screen was just too difficult.

But it shouldn’t be that way. What’s going on? All of us that build products are part of a professional community that refers to our customers as “dumb users.” That’s just wrong on all sorts of levels.

The fact is that all of us software developers, and I’m including the folks that work for me, are building automation software that’s overly complicated, difficult to use, hard to understand, and that treats the user as a servant. We expect compliance. We expect effort. We expect a lot of our users. And, in one word, that’s impolite.

So what would polite software look like? John Allen Robinson, Michael Covington, and Alan Cooper have all done a lot of thought on this and I’ll distill their findings here in my own words.

Polite software can be characterized as follows:

It Remembers Me. It knows that I like to see small icons when I’m looking at a directory of pictures and file descriptions when I’m looking at a directory of Word files. Polite software remembers me and how I like to work. Polite camera software would know that when I shoot a picture or a video, I want to see it immediately afterwards, and would give me that option. It would realize that when I shoot a video, I always use the ten-second delay timer, so it shouldn’t reset it. Polite software should get to know me and make what I normally do simpler and faster to do.

It Trusts Me. When I say I want to delete a file, start a process, or load a recipe, it should just do it. It’s insulting to confirm everything with me twice. I’m not three years old. Unless the consequences of my actions are irreversible, it should just trust that I know what I’m doing. There’s a great story that Jeff Bezos at Amazon tells. He said to his programmers, “Give me a one-click buy option.” They came back with a click-to-buy and then a confirmation box asking if you really want to buy. He asked them, “What part of one click don’t you understand?” One of our problems is that programmers distrust their users and customers.

It Won’t Lie to Me or Leave Me Wondering. Software should honestly say that task you asked it to do is complete or not complete. Windows should tell me when I clicked to start an app that it’s working on it. Instead, I just keep clicking, hoping that it will respond to me. My camera should immediately show me the picture. And more importantly, it shouldn’t lie to me like my survey software does, like when I check the box to add a comment box to the survey, but it’s not added.

It Should Give Me Control. When I turn on the iPhone, it’s to make a call or send a text. It’s polite to let me accomplish what I want without its (Apple’s) desires getting in the way.

It Simplifies and Diminishes My Workload. One example of this is the University of Georgia Class Scheduling System. The student class schedules are printed with building numbers, not names. But when you walk past a building, there’s a name on it, not a number. Every new student needs to consult a cross-reference list to find the name of their destination. Forcing a customer to perform a tedious or error-prone action that a computer can quickly and correctly accomplish is not polite.

So why do we have such impolite software? My apologies to my programmer friends, but it’s because we’re letting programmers build these user interfaces. Programmers care about one thing – the code: what language, how it’s structured, what rules they’ll use to code it, etc. They think code structure first and then build a UI to match the code. It’s why, when I take a picture with my new camera, I have to change modes to view the picture I just took. To the programmer, those are two different tasks. To me, the user, it’s part of the picture-taking process. Most programmers can’t see it that way.

I am arguing here that we all need to reorganize our development efforts. At my company, Real Time Automation, where we make Gateway devices, Archivers, Recipe Managers, and such, we’ve implemented a new process. The engineers don’t get control of the UI. They implement it, but the UI is designed by someone that is going to think about the user and how that person works, not how the underlying code works. We’re going to work hard in 2015 to make our software respect you and be polite. And with any luck, others will follow suit.

You’ll get to judge how well we accomplish that as we release product in 2015. I think you’ll like working with polite software.

Now if I could only get that pepperoni distributed correctly on my pizza…

John S. Rinaldi is president of Real Time Automation, which provides industrial networking technology to system integrators, machine builders and product designers in a variety of industries.  He is author of four books, including two technology books; Industrial Ethernet and  OPC UA: The Basics: An OPC UA Overview For Those Who May Not Have a Degree in Embedded Programming. There are a limited number of free copies for Machine Design Readers.  To request a free copy, visit the “ Contact Us”  link at

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.