I was writing a document this morning, and I had to reference the definition of "Good Software", so of course I googled it:
And I was stunned: It was nowhere to be found.
Come on Google! We're in November 2015 and you still don't know what "Good software" is??? How are we supposed to make happy users if we don't know what "good software" is???
I think it's about time we remedy that situation. Let's start with a very common simple definition that one hears frequently: "it just works".
This definition is somewhat helpful but not entirely sufficient either. A "hammer" just works, but if my user needs to drill a small hole in a wall and I give him a hammer, he will complain that my product isn't very good. So to actually measure the "quality" of a piece of software, we need to match it with the "need/problem" that the user is trying to solve. Yes, I'm recklessly discarding all the "internal" qualities of your software about how nicely organized and modular the code is and how lovely the UI art is. I don't care, and your users probably don't either. One can only judge a product by how well it solves a particular need for a particular individual in particular circumstances: You may manufacture and sell the best eletrical drill and carpenters across the world may love it. But if I take it to my shack in the woods where there is no power outlet, it's useless to me in that context.
So that takes us to our second iteration of the definition, and I'm going to authoritatively skip the circumstances part, because:
_It's my blog entry and I can
_I'm going to assume we're going to talk about software that is mostly used under "normal circumstances". You're sitting somewhere comfortably or uncomfortably with a device in front of you, or you're standing, or you're laying down, I don't care. For now, let's assume that you have a piece of software in front of you, you are in the appropriate setting to use it, and you want to know if it's any good or not.
_Finally, you will see that it doesn't change the conclusion by one bit. Even if you're running, diving, naked, in a hurry, sleeping, in the sun or under the rain, agonizing, high, or have lost the use of all limbs, the conclusion will be the same.
So circumstances are important, but we don't care for now. Okay, so second definition then:
"Good software solves a particular user need/problem well".
That's better, but still a bit too vague, the word "well" being too imprecise, let's try and refine it.
In the case of software, speed is often an important factor, right? If you click on the "add to cart" button, and it takes 10 milliseconds which you can't really perceive, you won't even think about it. If it takes 1 second and your brain actually starts to feel the wait, you will go "meah, okay, but definitely not great". If it takes 1 minute, no amount of spinning icons or progress bar indicators on earth will make you think the product is any decent. So to be "good" it has to be "fast".
What else? It needs to be reliable, but also work consistently. Reliable means it must not work extremely well 99 times and destroy your whole world the 100th time you use it. Consistently means it has to produce the same output given the same circumstances, no matter how good the alternative is. If you use a drill to punch a hole, if once in a while it refuses to drill and decides to order a free pizza for you instead of drilling a hole, no matter how much you *love* pizza, you still very much need it to start drilling *now*. Ok, so fast, reliable and consistent the software needs to be.
Next one, I'm sure you've all been bitten by. You search for a piece of software that can do X. After much googling, you finally install the software of the promised land. And then you try to make it do what you thought it could do, but really doesn't after all, no matter how many hours you spent raking the internet. So it has to be "honest" in its depiction of its capabilities, whether that's its UI, its documentation, its marketing website... I could even push it to say that it should be "humble", as you're more likely to "delight" your users by actually doing more than you promised you would... Fast, reliable, consistent, honest, more?
Ooooh, yes there is so much more, the list seems infinite.
It needs to be polite as Alan Cooper has taught us. It needs to be accurate but "just enuf", because it also needs to know when to approximate/summarize data/information as our poor brains can't deal with copious amounts, so that takes us immediately to the next item: It needs to be "easy".
There are (many) pieces of software out there, that actually have the power to do quite useful things, but are just so darn hard to use. From your user's point of view, there is really little difference between a broken software and a software that he can't use because it's too hard, the end result is exactly the same: He can not use your product.
I'll throw in one more: It needs to be thorough/hard working. Remember the 80/20 rule? "80% of the effects come from 20% of the causes". I hear it applied to software design *all the freaking time*, but people usually don't apply it correctly. It usually goes like this: "Hey, let's just implement this small thing, that way we'll solve 80% of the problem with 20% of the effort". From a user POV, I'm sorry to inform you that a problem 80% solved is *not* a solved problem, so don't expect them to *love* your product, as you're really leaving them to clean the mess you refused to deal with. If you want your users to love your product, you have to be prepared to really "nail" it, the whole nine yards. The 80/20 rule does work for software, but not like you may think it does. Software is about doing stuff for us dumb and lazy humans, right? Let' suppose that to complete a task, I need 10 minutes. If your software doesn't entirely complete that task, but effectively does 80% of the work for me, which means I will only need to "work" for 2 minutes while your software takes care of the other 8 just by pressing on a button, then yes it's pretty darn valuable, what I've seen times and times over is people applying this reasoning to justify poor man's implementations, pretending to solve "80% of the problem". When was the last time you were satisfied when your files were 80% copied? When your shopping cart was 80% processed? When you received 80% of your alarms? I guess it's an argument in favor of small applications that do very few things but do them very well...
It must also be safe and secure. Safe meaning that you won't hurt yourself if you use it, secure means that Mr. Robot will not be able to come and hurt you because you just happened to use that piece of software. Safety and security share one huge characteristic: You will always feel like you pour enormous amounts of money in them, yet it will never be enough, and your users won't give you any love at all for any of that investment, and sometimes will even complain about it! But destroy enough of your user's data, or have their Credit Card data hacked, and your business just might not live another day (well unless you're Sony, in which case people know your products are ridden with security problems already)
It doesn't need to be beautiful. I've seen plenty of good ol' useful working software that weren't fancy looking. Au contraire, I think a stunningly beautiful UI may be distracting or feel alienate some users, but I don't have a final opinion on this. Actually it doesn't need a UI at all. There are many command-line utilities that are pretty darn "good". So "beauty" doesn't really matter, plus it's in the eye of the beholder anyhow. But, it mustn't be ugly either. Ugly is definitely jarring/offputting.
Let's look at our little list again: "Good software" needs to solve a particular problem/need/task for your user, fast, easily, reliably, consistently, politely, accurately, thoroughly, safely and securely, must be honest/accurate in its depiction of its capabilities and must not be ugly.
That's a pretty thorough definition, of course I'm sure I'm forgetting things, but if your product can achieve all of the above, even I might be able to use it!
But let's be honest, that definition is dead ugly and you won't remember it. If you can't remember it, it's no good to you in your day to day job. So can we abstract this definition to something shorter and more useful? Yes, we can, and to get to my final definition, I'll shamely steal from Joel: http://www.joelonsoftware.com/uibook/fog0000000249.html
Well Joel actually has that whole explanation about matching the mental model, but even that's way too complex for me, so let me distill the essence for you right there:
"Good software" does... what you hope* it will! (and is not ugly)
*Within the limits of reason of course.
I'm sure it's a leaky abstraction, but as most abstractions, if it works 99.99% of the time, it turns out to be pretty darn useful!
Note that I now realize that I could have saved you 3 pages of reading by just defining "fast" and how "fast" is relative to your perception/expectation, boom voila done. Also note that I told you that circumstances didn't matter, and you can verify that by yourself as an assignment for next week.
I'm pretty sure you can generalize this definition to define a "good product", so feel free to replace every occurence of the word "software" with "product" if you're so inclined
Now that we finally have a definition of what "good software" is, next time we'll see how to create it.