Good software doesn't mean incomplete software
Imagine for one second that you had to make a choice. On your left, you have an incredibly complex machine with 100 different flashing buttons and indicators and LEDs and -- why not? -- a lot of beeping noises. On your right, you have a very simple panel with five buttons, no noise, and only a couple of analog instruments.
Those two machines have something very important in common. Can you see what it is?
These machines controls how you make cabinets. They control everything: how the wood is cut, pieced together, and packaged for the customers to pickup. And yes, let's make it so that it packages everything flat, like Ikea furniture.
So, which one would you pick?
Most of us would tend to pick the one of the right: with such a simple machine, there surely is a lot less to learn and a lot less room for mistakes. With this simple machine, you will be sure that the doors won't be the wrong size, because it will calculate everything for you. However, after a while, let's give it a couple of months, you start discovering the limits this simple machine imposes: sometimes, you might _want_ to have the door a little bigger. Or the cabinet's foot in a different place. What you need to learn then, is how to _hack_ the simple machine so that it does all those funky things you really want to do. Eventually, you might end up wishing you had chosen the machine on the left.
Some of us would tend to pick the equipment on the left, the complex one. There is the challenge for learning such a complex piece of machinery, and there's the love for the amount of control you can have about everything. The doors will be exactly as you desire, and if anything is wrong, at least it was _you_ making the mistake. A couple of months later, however, you start getting tired of it: you wish the machine _would_ calculate the doors' sizes for you since it's such a repetitive process. So, you start hacking the complex machine so that you have to do as little as possible -- take the noise out, turn off a few indicators and LEDs, and... wish you had the simple machine in the first place.
With software, you often get a very similar scenario. Microsoft Windows could be the complex machine, and OS X could be the easy one. But they are just the most common examples: I am sure you can all think of software that is obscenely hard to use, or just too simple to work with.
At the beginning, I wrote that those two machines have something in common. Can you tell what it is yet? If you are a software developer, you will probably agree with me when I say that _they are both the easy, lazy way of doing things_. Creating a monster that leaves everything up to you, or creating something that is so dumb that you end up hacking it to make it work, shows that the programmers were... lazy.
Creating software that is both powerful, _and_ easy to use, is the real challenge. It's like juggling while going around with a unicycle, and singing: it's the fine art of finding a balance when it seems impossible to do so.
Sometimes, less is not better, but it's just too little. Sometimes more isn't better, but it's just too much. And yes, going around on a unicycle while juggling balls singing "God Save The Queen" might sound so hard that it's crazy, but... people do it. So, maybe it is hard, but hardly impossible.