The 2009 FIRST LEGO League competition is behind us. As a coach, it has been an amazing experience of the good and the not so good. We learned tons, especially about how to deal with frustrations spawned from having to use a very poor development environment, i.e. LEGO MINDSTORMS NXT software. Following my mother’s advice, if you can’t say anything nice, don’t say anything at all, so I’ll focus my energies on how your users’ emotions dictate their perception of the quality of your software.
- Don’t make me feel and look stupid
- I need a dependable buddy
- Grow with me
- When you piss me off, say you’re ‘sorry‘
- When it’s time to part ways, don’t get angry
There are various opinions on what makes good software, especially from the perspective of developers and designers. I did stumbled upon Joel Spolsky‘s article titled Good Software Takes 10 Years. Get Used To it. Though Joel presents a valid argument, my own experience tells me the opposite can also be true: as software matures, odds are that it will become bloated, complicated and crappy.
Here is a question: what is in your top 10 list of great software? I truly struggled with my list, but here goes nothing…
- Vi – yes, really!
- WordPress – contradictory to my previous statement, this software is getting better with each year
- Django – love the development platform and the user community
- Evernote – it just works, anywhere and even for free
- Google reader on iPhone – it simplifies information overload
- iSync – because it connects my life… when it works……..
- … and that’s all I could come up with for my top 10
If we look at what makes bad software, it usually boils down to not knowing who your customer is. Even then, as my realtor used to say, “For every house there is a buyer. The trick is to be patient and to wait.” Given that premise, for every piece of software, there is a buyer. We just happen to refer to that person as the ‘visionary‘. 
True, what makes great software is in the eye of the beholder. And when it come to software, there are many beholders: developers, testers, customer support, shareholders, users, purchasers, news media, your boss, your boss’ boss, …. Perhaps there is a high correlation between beautifully written an documented code and a great software, but the reality is that your users rarely care about how well the code is written. However, research has shown that source-code metrics that show high internal design and code quality do correlate with maintainability of code. And your users do care about this from the aspect of backwards compatibility, quick time to issue resolution, time to market with new functionality and such.
Good software is as much about emotions as it is about the overall software quality, features, ease of use and such. Case in point, my own emotional turmoil as I struggled to program robots with the software product that shall be nameless…. Yet, in our product development process, we focus on what we can quantify (defect count, performance numbers, …) and less on understanding our users’ emotional feelings toward our product. To differentiate your software from everyone else’s, start paying attention to what emotions you stir in your customers.
Don’t make me look and feel stupid
Especially in front of a group of tech-savvy pre-teen boys! 
Fear is a very basic human emotion. We all want to be seen as intelligent individuals. We see our environment, our tools as extensions of ourselves. Not only we don’t want to be seen stupid, but we want our choices to shine as well.
Recently Strand Consult suggested that iPhone users are suffering from a form of Stockholm Syndrome – the condition in which the kidnapped begin to show loyalty to their kidnappers. Personally, I don’t understand how a built-in radio in my phone would make my iPhone better for me (yup, I am one of those sufferers….) But it does highlight the intimate relationship people build with their environment, applications and mobile phones.
If your product is preventing your users from experiencing your promise, you are making them feel and look stupid. In my case poor quality software coupled with poor documentation on how the programming environment interacted as a system resulted in very unhappy kids and coaches. The fact that the company charged for upgrades made the overall emotion even worse. It is one thing to be stuck with a bad software, it is another to actually have to pay for the privilege….
Need a dependable buddy
Our brains work on autopilot. We automatically search for patterns and respond accordingly. Given that, consistency is key to how fast we achieve mastery over our tools. Take Apple’s Aperture for instance. I recently moved from iPhoto to Aperture. And, I want to love Aperture… Yet, this software puzzles me, as with each new interaction I get a different pattern and response combination. I haven’t figured out its mystery, but I still want to love Aperture…
As your software gets feature rich and flexible, avoid the natural tendency to bloat it unnecessarily. But even more importantly, maintain the consistency and natural patterns that exist in your software and in your users’ environment. Your users have come to depend on them. Take file system operations as an example. We are used to copying/moving/renaming files, so your software should not throw a fit just because I copied a file from one folder to another.
AND grow with me
Who wants to be a beginner forever?! As humans, we are wired to excel, to move quickly from beginner to intermediate and maybe even expert status. Face it, if we can’t feel competent using our tools, we move on. So what does that mean for your software?
Alan Cooper, Robert Reimann and David Cronin emphasize the need to optimize for the intermediates in About Face 3: The Essentials of Interaction Design
- rapidly and painlessly bring beginners into intermediacy;
- avoid putting obstacles in the way of intermediates who want to become experts;
- keep perpetual intermediates happy as they stay firmly in the middle of the skill spectrum;
Looking back, if all I needed was to move a robot forward, backward or side to side for small well defined blocks, the software product that shall be nameless might have been fine. But as I want more, it’s time to dump this software and move on to one that will enable me to grow.
When you piss me off, say you’re ‘sorry’
This is a basic and fundamental principle when it come to writing software. Yet, writing understandable error messages seems to be a lost art… Though I appreciate relaunching the program immediately in the case of a crash, why did you crash in the first place? And you look guilty — what else did you mess up in the process??!
When it’s time to part ways, don’t get angry…
Providing uninstallers and tools to migrate existing data/files to other platforms might go against common sense, especially when we consider the cost of switching as a competitive advantage. Yet, if your customer has already decided to dump you, the least you can be is courteous and polite. Think about it, if we stay friends, you have a better chance of being introduced to another friend of mine, or for me to consider another one of your products. And as you are leaving, do make sure to completely clean up after yourself….
Finally, remember the reciprocity rule of human behavior. Over time, people share similar attitudes and feelings towards each other. So, if you don’t respect and appreciate your users, eventually they will catch up and you will be out of a job! Next time you are evaluating the quality of your software, make sure to consider how your product makes your customers feel.
Happy Holidays!
Technorati Tags: software quality, good software
sharing insights and practical ideas on product strategy and technology management
