Good looks vs. runs well

This is another one of those posts that I just hate to have to write. So why do I have to write it? Because I have to be 100% honest with you guys, because you can smell deception from a mile away, and I have a really hard time putting effort into something that I do not believe 100% in, even if I used to. What is this horrible thing in my mind? “Looks good” is more important than “runs well” to most customers, at least the ones who authorized the purchase order.

“Can we get that icon in cornflower blue?” - Richard Chesler (the manager), Fight Club
“Is that server available in black or silver?” – A former manager of mine

This is exactly what I mean. To a T. Customers notice what most developers consider the “silly stuff” long before they see glaring technical problems. If you have a typo in an error message, it won’t occur to them that they should not be seeing the error message at all, they are worried that they see a typo. I see this time and time and time again, from customer to customer, industry to industry. The non-technical folks at your customer (or potential customer) simply do not feel comfortable with testing or even trying out the software; they would much rather watch you, a tester, or someone else go through it while they look for things that do not meet expectations. The network engineer does not care what color the switch is, as long as it is easy to manage and works right. The CIO wants a pretty looking server room when he takes customers on a tour, and tells the networking folks to “make what we bought work somehow”.

Another point along these lines is that nearly everyone from your customer (and even within your organization) will have their pet features. Remember when you all sat down to figure out the requirements, and some features were kept and some were shot down? I promise you, the person who argued the loudest for a particular feature will be the only one who notices if it is not there. And oddly enough, people who argued against something that was shot down will forget that it was shot down, and the person who wanted it will wonder where it is, so all of a sudden, everyone at the customer is asking where the “missing feature” is. So when that initial test comes, these folks check to confirm that their pet feature is there, and completely ignore the rest of the application, and give you sign off on an application that does not truly meet their needs as a whole.

And this is why precise requirement documentation is so crucial. Because a group of people can spend two days arguing over the color of an icon (cornflower blue versus periwinkle) or how a set of data should be displayed (pie chart or bar graph?), meanwhile, the icon does nothing and the numbers being displayed are flat out wrong. It is a lot easier to go back and say, “these are the specs we all agreed to” when they are precisely and concisely written down, instead of being a bunch of vague bullet points in a PowerPoint presentation, or musings in a huge email thread from six months ago, or something that was discussed over the phone but never written down and confirmed.

On top of all of this, the natural developer reaction is to want to focus on the technical issues. We are technical folks, right? It’s what we like to do, which is why we are doing it. Most programmers would rather spend two days trying to debug an intermittent data concurrency issue in an n-tiered application, than to spend two hours with the already made list of UI typos and correcting them. I’ve been guilty of this time and time again.

Ironically, the end users tend to not care nearly as much about presentation as their managers do. To them, functionality is king. A few companies ago, we used an antiquated application which was accessed via a VT100 application. 80 x 40 ACSII mode, you know the kind, where the corners of the boxes are plus signs and the edges are hyphens and pipes. I never once heard a floor worker say anything like, “gee, it would be great if this was a Web app so we could see the company logo or have rounded corners!” Instead, everyone complained that it was slow or had record locking issues.

When I was doing development, I knew this truth in the back of my head intuitively but never consciously put my finger on it. As a result, I always pushed to get the prototypes into the hands of actual, day-to-day end users for the customer testing, not the managers who passed off the requirements to us. I could not stand hearing about the colors of the chart or the placeholder graphics, when I had poured blood, sweat, and sleepless nights into a technical kick butt system that fulfilled every real user need.

At my last job, my manager was very firm about the idea that it is better to give a pretty, yet non-functional prototype to the customer up front that an ugly but working prototype. While I disagreed with him from the standpoint of the development cycle (my coding method is to make the application layer presentation agnostic, so developing features is not dependent upon the presentation, which always seems to shift), I now see his point from the business perspective. When our customer had technical people or end users doing the customer side of the testing, my “features first, looks second” approach was great. Users would make tweaks to the functional requirements, and since no presentation was tightly tied to the features, change was easy. However, for the customers who had the managers doing the testing, it was usually a mess. I would beg them to ignore the presentation and focus on the features. I would ask them, “Does this do what you need it to do?” and get responses like “I suppose so, but this text looks a bit too big.” Then, two days before “go live”, real users would see it and all sorts of unidentified requirements would crop up, and “go live” would get pushed back.

It really is a tightrope. While I would love to drop a great looking and a great working app on the customer for the “first draft”, it often is not feasible. For my last few projects, I have been taking into account who will be doing the initial testing into consideration, and I have found that this makes all of the difference in the world.