You can tell the difference between a Kia and a Mercedes with your eyes closed, can't you? It's more than the look of the car; it's a host of little experiences that tell you how the car was built, and that someone really sweated the small stuff.
You can feel quality when you reach for a knob - it's in the right place, even though you've never thought about what the right place is. You can feel it when you twist the knob or flip a switch - you can tell that knob is going to be working just fine the umpteen-thousandth time you reach for it.
Doors are a good place to look for quality. I owned an Acura a couple years ago, and it had a little electrically-actuated finger that grabbed the door when it reached the door frame and pulled it in tight to latch. I hardly ever noticed it until I got rid of the car, but then I really missed it. Other high-quality cars pride themselves on a solid, muted "chunk" that could just as easily come from a bank vault.
Software has quality, too.
You may not be aware of the dozens of subconscious signals that transmit software quality to you, but they're there, too. The first thing that people think about when "software quality" comes up is coding quality - how many bugs are there?
You've probably seen the jokes that talk about using the horn, turn signal, and gear shift to restart the car when it breaks - that's a reference to coding quality. We don't want our cars to leave us stranded by the side of the road, and we don't want our software to puke its guts out all over our screen every time we look at it sideways.
Coding quality gets a lot of attention from QA departments who want to automate them away, and from development departments who want to unit-test them away. Coding quality improves when teams work together, and when individuals learn the craft of software development (hint: pick up a copy of Steve McConnell's Code Complete).
But coding quality isn't the end of software quality.
Design quality is perceptible in the layouts of screens and the ease with which new users find themselves around for the first time. It's like the bank vault car doors.
What is platform quality?
Platforms show their usability in all these ways, but there are other aspects of platform quality that are more subtle. I've been working pretty extensively with two different platforms over the last several months, and I am struck every day with the difference in "feel" I get from these two platforms.
Drupal is a Content Management System (CMS). It's the software that powers this blog, and I've also deployed it into a couple other environments. I have worked with other LAMP-based CMS systems (PHP-Nuke, PostNuke), and I have no problem putting Drupal on a pedestal above those other platforms. Drupal does enough things so very, very well that I've begun to think of it as a general-purpose web platform rather than just a CMS.
I like it a *lot*.
SugarCRM is a Customer Relationship Management System (CRM / CRMS). It's a Salesforce.com competitor, and it's available in open source (Community) and two paid versions (Pro and Enterprise). Even though I'm going to pick on some aspects of SugarCRM, I have to begin by saying that I really admire what they've done. The value to be had here by customers relative to the commercial alternatives is impressive.
But where Drupal inspires confidence to look for new places to use it, SugarCRM makes me want to stay in its comfort zone. I'm pretty sure SugarCRM is going to do well at the things it does natively, but extending it hurts. Salesforce.com is actively working to transform their CRM platform into a general-purpose web platform, but SugarCRM isn't ready for that yet.
Even though these are two completely different applications, they are similar in the sense that in most implementations, the "stock" product isn't quite right for the job. That's clearly true for Drupal, where you are very likely to customize the UI and add modules to get the right mix of functionality for your site.
SugarCRM is more likely to have most of what you need out of the box, which is a testament not only to the complex nature of the CRM space, but also to the high level of functionality in the box. It's probably also fair to point out that the business processes and data relationships in CRM are more complex than for CMS, but for now, I'm going to ask to have my cake and eat it, too.
I'm going to compare these two platforms in a number of areas, pointing out the ways that each of them build up or tear down my confidence in the platform, and where applicable, showing where an idea from one would work really well in the other.
(stay tuned for more on this in future posts)