I believe people experience software usually across two main dimensions, which is a sliding scale:
- Visual design: Polished to Primitive
- Polished: Cool slick, and well styled cohesive and easy to use. Most Apple products fall into this vein.
- Primitive: The controls are there, the aesthetics sure aren’t, but gets the job done. I’m thinking the airline reservation system, DOS, or early eBay web site. (Am I’m dating myself?)
- Code quality: Robust to Buggy
- Robust: Elegant, Well written, qualified code which handles errors gracefully and is divided and designed to be maintainable over time, handle changes well, and makes sense
- Buggy: Spaghetti-code, unmaintainable behemoths, obscure hacker crap code which is ugly to read, difficult to work with, and cryptic at the best of times.
So, examples always help here. Think Polished like the look of, say these sites:
And here’s Primitive:
- Yes, my own http://marketacumen.com is primitive, methinks
As for code quality, this is something which is based on experience, but it’s not something you can see at all. It’s just there, or it isn’t. The only way to find out is to use it.
People often make snap judgements about software quality using the Visual design instead of the experience.
- Primitive/Robust. If software is written correctly, good software can have a primitive look, yet still operate correctly almost all of the time. That’s the goal. Because I have the design sense of, well, a developer, I write a lot of software like this. Works quite well, but could use a little design help. Google’s early home page was just this. A single search box, but it worked flawlessly, was fast, and you could do some more advanced things if you wanted. But it looked primitive, no? Also, UNIX is exactly this.
- Polished/Buggy. There’s a lot of this around. To date myself, Windows 95 was probably in this vein. It looked awesome at the time, but it was basically shining up a turd, so to speak. I see lots of software like because fixing underlying code is difficult, time consuming, and risky to update and fix (Read: expensive in terms of time and or money.) Often when software is buggy it’s symptomatic of larger issues which are harder to fix (e.g. poorly architected, bad or fatal design choices). On the other hand throwing a new skin on something is usually easy and cheap to do. There’s an added bonus that people will think something changed underneath when often, nothing has changed.
- Polished/Robust: Basically, good software all around. Google, Gmail, FaceBook, 37 Signals, LinkedIn, these are all well written, bug free, easy to use, and work well. You know they put a lot of effort in the quality of their software because … really, when was the last time you experienced a bug on these platforms?
- Primitive/Buggy. Most software starts off this way, and few lucky projects graduate to another classification. Generally speaking, this software isn’t often used. But sometimes, surprisingly more often than you think, people use buggy software designed in 1989. (That’s bad.)
Of interest here is that people often make decisions based on the aesthetics of a program. If it looks good, it must operate well and do what I want, right?
What’s interesting is the learning curve. You hope software starts out as Polished/Robust, but given enough problems you start to see that it’s Polished/Buggy.
I once bought a Barracuda load balancer which looked polished, and the user interface was slick. Underneath it was a pile of crap, however. The systems rebooted spontaneously, and I returned them for a full refund (no, that’s not my review). That was in 2008, so I’m hoping they’ve gotten their act together since then. I swapped that for a far more expensive pair of Coyote Point load balancers which were slightly less slick, but man – they worked like a charm and never failed me, so they got my business.
I’m going to update this page when I think of products which are on my lists.
Shined up turds
And the list is:
If you want to add to the list, please comment!