A few days ago I was ordering lunch at a barbecue joint in Austin, Texas. The menu described a lovely plate of three sausages, and suggested six different sausage types to choose from. I love a good sausage; and I am especially fond of Bratwurst. So when the waiter came by I told him I wanted two Brats and a Keilbasa.

The waiter nodded and proceeded to tap on his hand-held POS terminal. Over the next 60 seconds his taps grew ever more punctuated and his expression grew ever more frustrated. He started muttering words under his breath – words that I have heard so many times before: Why won’t it let me…?

Apparently the genius developers who wrote the software for the hand-held POS terminal had not considered that a customer would want two of the same kind of sausage. The terminal simply would not allow the waiter to add bratwurst twice.

We had a large group at the table, and the waiter had only taken half the orders at this point; but his frustration was so great that he abandoned the table and ran into the kitchen to resolve the issue. He came back a few minutes later and told me that the kitchen would do their best.

Software is supposed to make life easier. Software is supposed to ease and enable the job of users. All too often, however, software is constraining and restrictive. If you don’t do what the software expects, the software fights you and stops you. And you mutter under your breath: “Why won’t it…”

In the early days of software we were generally forgiving of this kind of thing. It was enough of a miracle that we were getting any automated help at all. So the inflexible state machines that programmers employed in those days were a small price to pay for the massive improvement we gained from the automation.

But those days are gone. Nowadays we expect software to get out of our way. For example the hand-held POS terminal used by a waiter should be more flexible, and less constraining than a pad of paper. That POS terminal should not get in the way.

Now before you try to put all this off on the UX people, remember that you are writing the code. It is your fingers on the keyboard. It is your mind engaged in the task of making the machine do what the user needs it to do. We expect the UX people to be smart. We expect that they will try to describe a system that will stay out of the users’ way. But that doesn’t mean that we should blithely and blindly implement that specification. After all, nobody knows the machine better than we do.

Remember that as a programmer you are also a stakeholder. Your reputation is on the line. You need the product to be a success. So play with the software. Pretend you are a user. Walk through the use cases. Invent new use cases. Try to find areas where the software inhibits or constrains those use cases.

Yes, I know, the UX people will be doing this too. Yes, I know, there will be alpha and beta trials (probably). Yes, I know, UX is not your job. But do it anyway; because your name is on that product.