Friday, April 28, 2006

Bob and the Rusty Fuel Truck

Just out of college, I got a job working at a general aviation airport in Southern California. Of the many jobs I got to do, such as yard and field maintenance, customer service and even crash fire rescue, most of my time was spent as a fuel jockey. I got to pump fuel into aircraft ranging from Cessna 152s to Aerocommanders. Every now and then, I even got to drive the 10,000 gallon bomb on wheels to someone's hangar for an on-site fueling. It was a great job that I still have fond memories of to this day.

On of the senior employees I worked with was Bob. He was the proverbial "old sage", full of wisdom and experience, peppered with doses of occasional sarcasm and senior frustration with Gen X. Bob took me under his wing and taught me all sorts of thing, like how to drive a skip loader, work a steam roller, use a concrete cutter, etc. But the most memorable lesson he gave me was a lesson in peoples' perceptions.

At the airport we had three fuel trucks. We had two shiny black and white trucks that we kept parked in "the fuel pit". We also had an older dingy truck with faded orange cab and dingy white paint feeling off of the fuel compartment. Under that the metal appeard slightly rusty. It was the rusty fuel truck. We kept it parked in the back of the office, where it couldn't be seen unless you went looking for it.

One of the newer trucks held 10,000 gallons of 100 octaine, low lead fuel. The other had two 5,000 gallon tanks. We would dispense 100LL out of one, and 87 octane out of the other. Since we could only hold 5,000 gallons of 87 in the one truck, we would store the remaining 87 octane in "the rusty fuel truck". When the 87 ran low in the truck in the fuel pit, the staff working graveyard shift would drive the rusty fuel truck to the pit, transfer more 87 to the truck in the pit, and drive the truck back to the back.

Every morning, we would "sump" the fuel trucks to ensure we only dispensed pure fuel. This entailed opening a valve that was at the bottom of the fuel tank on each truck and allowing fuel to flow into a plastic bucket. We would check this fuel for water and debris. And we would keep sumping until the fuel was a bright color, with no water bubbles or flecks of debris. 100LL was bright blue. 87 was red.

When pilots came to buy fuel, they would taxi their plane to the fuel pit, or we would drive out to their hangar to tiedown and fueld 'em up. But we didn't dare fuel them directly from the rusty fuel truck. The pilots had the impression that if the truck was dirty or rusty, then the fuel dispensed from it was either dirty or rusty. The pilots' perceptions were their reality. Imagine flying at 8,000 feet and wondering if your fuel was contaminated to the point that your engine would seize! We knew the fuel was clean, but the pilots wouldn't trust it. That's why we always fueled from the clean trucks in the pit.

So how does this apply to software?

It has been my personal experience that software with an unpolished UI generally reflects the quality of the code underneath. While I can't name specific products, you can see them for yourself. These are the the apps where pixels don't line up, or the default icon is left on the form. Fonts may be mismatched, or the UI is just plain ugly.

I've had to use software where I just went "eeew", "ugh" "barf!" on the first look. Usability was often awkward at best. I had the good fortune to work on some of these applications in my day, after using them as an end-user. And in all cases, when I looked at the source code, the quality wasn't up to snuff. I used to be surprised, but am not so much anymore. I mean, if we don't make the extra effort to spit polish the user interface, why would we go to a little extra effort to make sure the code is well thought out, readable and maintainable?

They say you can't judge a book by its cover. But I believe you can judge software by its user interface.

Monday, April 24, 2006

Back in the Saddle

The "Software According to Steve" blog was originally created on a server hosted by my employer. However, as time went on, there were topics I wanted to post that I felt should not be hosted on an employer's real estate. As a result, I moved the "Software According to Steve" blog here.

So why does it have this title? Simply put, when it comes to software development, I tend to think a little differently than many of my cohorts. I've worked with good programmers as well as bad. I've built good programs as well as bad (but that was many many many years ago ;) ). I've seen things done right, and I've seen things done wrong. I believe that by changing our mindset about how we build software, we can change the following axiom:

Features, Time, Cost... Pick two all three.

I chose this title because I have a deep passion for improving the software development process and creating products that are easier and more enjoyable to use. I hope that this blog will reflect this passion, and that in contributing to it, we can all learn something and be better for it.