Complicated software looks like hard work, but does that make simple software easier. I would say no. In fact I think it's harder to produce simpler software than complicated software.
At the weekend I got into a conversation with my Dad about complicated software. My Dad is a draughtsman. He puts together the drawings for piping installations such as refineries and oil rigs. He uses software on a daily basis for his piping designs, but it wasn't always done this way. When he started in his career nearly 40 years ago there wasn't a computer to be found near the desk of any draughtsman. Everything was done with pen and paper. Simple tools by today's new tool of choice, CAD software.
Over the last couple of decades the mouse has replaced the pencil as the draughtsman's main tool for work. In this time the market for CAD software has boomed and with it come some of the most complex software I have ever heard of. My Dad has made the gradual change to CAD over the years through a number of training programmes and plenty of on the job experience. His biggest bug bear though is the software. In his opinion it is too complicated.
For over a decade now I've heard many complaints against software being too complicated. Complicated software isn't the root of the problem though. Software starts with people and what those people want. These are the initial requirements of software, what we expect it to do. Given enough time, and no constraints, any software product can go from simple and easy to use to bloated and complicated. In the past it was thought that a software product rich in features was the way to sell it. What happens over time though is that the product continually grows and grows as it caters to more and more requests until it becomes just too big and complicated to use. Those original features that made the software a hit have become bogged down by other quick hit features that only cater to a small subset of users.
We software developers are a bit older and wiser now though and we've learned a lot from those first days of commercial software. The main thing I think many software developers have learned is that it is okay to say no to a request. This is perhaps the hardest thing to do, we want our software to be used by many, but that doesn't mean catering to every request. Saying no to nine features, but yes to one is our way of saying that we care about the software we produce. If a feature doesn't fall within the general mantra of the software then we should say no to it. Yes, we might gain a few more users, but in turn we could end up annoying half of our existing users.
The thought of complicated software has made me re-assess the projects that I am working on and how they can be simplified for the people that use them on a daily basis. It's also made me question requests from clients for changes to their products. I could simply take the money and add the new feature, but by questioning that feature I could be opening a new discussion with the client to find the exact source of the problem and deliver a solution that will simplify the software instead of complicating it.