after-header

Fixing technology blunders…or not.

Confusion arisesThis morning I stopped by a popular coffee/donut chain franchise. I went through the drive-up placed my order for two items. I had a vague idea of what the total should have come to. I pulled up to the window and was told by the cashier a price that was several dollars less than I expected. I asked if she had gotten both of my items and she responded with “shhh. I rung it up wrong.” Ok, now I’m not going to make a big deal about something that will save me a little money but something struck me about this situation.

I started to think about what might have actually transpired and it seems there are at least three possibilities.

  1. The cashier knew she made a mistake but was too lazy or disinterested to fix it.
  2. The cashier chose me for a Random Act of Kindness at the expense of her employer.
  3. The cashier realized she had made a mistake but didn’t know how to correct it.

While the first two options are possible, they don’t seem likely. This person didn’t strike me as lazy, disinterested, or enough of a radical to purposely enter the order incorrectly. This leaves option number three. This order was placed in a drive-up. This means that once one order has been entered it moves into the que to be paid and another order is taken. I’ve worked in fast food style drive-ups as a cashier, and while my experience is dated the option existed, even in the early 1990s, to correct an order at the time of payment. However, you had to be fairly comfortable with the Point of Sale system in order to make the changes. This lack of understanding could have been because the person was new on the job, lacked proper training, or just couldn’t keep the steps required to change an order in the computer in her head.

It’s possible to relate this situation to other areas involving technology and software. I’ve been really struggling with getting templates for a client project working just right. And just letting some of the details slide becomes very tempting when the software is jam-packed with bugs and “design features” that make template development a nightmare. How often do we ignore a problem or mistake because we are not comfortable enough with the technology that we are using to fix it? The problems could stem from glitches and usability issues in a piece of software, lack of documentation, or lack of time and inclination to really master the ins and outs of software. Do we use a workaround instead of finding a solution? Software is sometimes underdeveloped or released with so many issues that workarounds are the only way to survive, but what if the answer is there, hidden in a menu or a toolbar?

What level of effort do you place into making sure the work that you produce does not contain recognized but ignored mistakes or fixable workarounds? On the other hand, how much effort should be given to an issue before a workaround used instead? There must be a point where a workaround must be used when the solution is not apparent or just plain impossible. The challenge, I guess, is to determine when to strive for perfection and at what point to accept defeat.

Creative Commons License photo credit: aeu04117