I explained to my uncle that “M” stood for Megabyte, and “K” stood for Kilobyte. That a simple calculation to convert “K”s to “M”s was to take the last three digits off the “K”s and you had the size in “M”s, give or take one. That he had 16-17 Megabytes of data attached to his email, and he can only have 10.

His response was to wonder (1) why didn’t the client just tell him he had “too much data,” and (2) why did the program give him Ms AND Ks, instead of picking one?

My reply consisted of (1) it did, that’s what the message said, and (2) because the programmer was thinking like a programmer.

See, my uncle is a very, very smart man. He worked in a video arcade as the guy who rewired the arcade machines when they exploded when somebody poured a Coke on them. He knew how the machines worked in and out. And got paid good money. When he moved back to Texas, he took up industrial and residential electric work, and is now a fully licensed foreman who’s in high demand all through the area. When he says “I won’t take a job that pays less than $20 a hour,” it’s not because he’s picky, it’s because he doesn’t have to. Sharp as a tack. But he’s not a computer pro. Not a problem, people can’t be pros at everything. This ain’t the 1700s, where you can pick up a test tube and learn everything known about chemistry in a few days.

But why would a programmer write a error message for an email program that would be unreadable to end users? Because it’s perfectly readable to him! When my uncle read out the message, my first response was “You have about 7 Megabytes too many attachments. Send a second email.”

Therefore, a programmer checking his work would think this was a great error message. Not only does it tell you that the email can’t be sent, but it tells you why. The limit is in Megabytes, but email messages are typically sent in Kilobytes, so the data is already there. See how helpful I am! And the unit conversion between Ks and Ms are very easy; programmers do it 10 times a day and wouldn’t even notice it.

That’s why we have end user testing, to try to catch these things that programmers won’t notice. It’s just a simple conversion of units! But for an electrician trying to send an email, it was as opaque as to him as if he had told me that I had a single pole dual throw make-break when I need a dual pole single throw break-make. It makes perfect sense, if you’re used to it. And if I think about it for a minute, I could figure it out most likely… but the point is, his error message is useless to me as it’s formatted. But it makes perfect sense to him.

So, what’s the moral of the story? Well, moral 1 is, try to be sure that all users of your product can understand what you say. We have an extensive testing process here at SoftLayer to make sure our data screens are usable without any confusion. Moral 2 is that programmers don’t “actively” attempt to “keep people from using their computers” by “making their programs too complex.” For us, it’s completely transparent and useful, as useful to us as a circuit diagram is to an electrician. Just let us know if we make something a bit to opaque; it wasn’t on purpose, and sometimes it’s an easy fix. We were just thinking like programmers.

-Shawn

At the fast food restaurant, every order is entered into the cash register at the front of the line, processed by the computer systems on site, the orders are relayed to the kitchen in realtime and displayed on monitors, and various thermal ticket printers spit out meal tickets to be affixed to the various food items to describe their state (Double Cheeseburger, No Pickles, No Onions, Add Secret Sauce). It’s an amazing dance of software.

But I noticed that my friend the grill cook was constantly complaining about the system. Apparently, the order processing is really real time. When the guy up front presses the “double cheeseburger” button, it immediately lights up in the back but it doesn’t alert you that this is an order in progress! So, if the cooks are in a rush and just preparing orders as fast as possible, they might already have the pickles on the burger before the lady up front presses the “No Pickles” button, updating the display. Also, updated items are NOT IDENTIFIED by the system, so if the burger is already wrapped and the burger man is already moving to the next little square, it might not be caught! (Keep this in mind: most order “errors” at this internationally recognized fast food restaurant are caused by slow order takers, or slow customers, or customers who change their mind at the end of an order (Oh, could you make that burger with no onions?). Remember, if the guys in the back are rushing, get your order together in your head before you speak. If you say “Double Cheeseburger, no pickles, no onions, add secret sauce” just like that, it’ll pop into the system the right way!)

My question, of course, was “Why not rewrite the cash registers to be more awesome?” See, the old registers tied into a small computer in the back room that tied into the monitors in the kitchen. All state was held on that one machine, so obviously as soon as it was updated, it would appear on the monitors. But I couldn’t figure out why they kept using this stupid backwards system. It’s 2008! When I worked in the local greasepit in my small town, we used paper tickets we were more efficient than this fast food restaurant’s system! So why haven’t they updated? Simple: the people who can fix it aren’t there to use it.

Aha! That’s what makes SoftLayer so awesome. See, our programming staff is right here, in the same office as everyone else (except for those people who work in our datacenters, but they have our internal IM, email, and phone numbers and know they can contact us at any time.). If something breaks, or if something is built in a backwards or strange way, we know immediately and can turn around and fix it. In fact, we have a whole lot of programmers, as a ratio of developers to normal people. This high ratio allows us to have the best control portal in the world, and to add features quickly. See, if only developers worked at that fast food restaurant, and saw how the system was used, and were allowed to make changes (another awesome bit about SoftLayer: management is open to change. You’d be surprised how many obvious changes simply are not allowed by management in some dev shops…), then it would be a much easier place for everyone involved. And maybe I’d get my Double Cheeseburger right. Without the onions.

-Shawn