Unfortunately, that hasn't been my experience. Everyone wants software to be easy, but most people (by which I mean clients, management, and anyone else who's ever asked me to build software) have no opinion one way or the other about simplicity: They want it to do exactly what they want, the way they want, regardless of how technically feasible or user-friendly that ends up being.
Simplicity is an ideal I see a lot more among tech people (myself included), and while I think it's nice to aspire to, it's definitely not something I've seen as a request, requirement, or even preference among the kind of people who are willing to pay others to build things. They want what they want, not a simple implementation of what they need.
Simple is good, but the thing you really want is orthogonality - the ability to change one thing without affecting another. Generally, you get that by moving toward small, focused abstractions.
As another child comment identifies, we should not confuse simple with easy. Clients want easy software, and they have little care or understanding of the complexity. That's OK, on its head, but it is our responsibility to share and teach this side of the software's lifecycle with "management" and "junior" developers. Rich Hickey, author of Clojure, had a great talk on simplicity and easiness of software [0].
Comments
In my experience, practically everyone agrees that software should be simple, but not everyone agrees on what simple is.
Unfortunately, that hasn't been my experience. Everyone wants software to be easy, but most people (by which I mean clients, management, and anyone else who's ever asked me to build software) have no opinion one way or the other about simplicity: They want it to do exactly what they want, the way they want, regardless of how technically feasible or user-friendly that ends up being.
Simplicity is an ideal I see a lot more among tech people (myself included), and while I think it's nice to aspire to, it's definitely not something I've seen as a request, requirement, or even preference among the kind of people who are willing to pay others to build things. They want what they want, not a simple implementation of what they need.
Perhaps the reason I haven't shared your experience is because I primarily deal only with tech people.
Simple is good, but the thing you really want is orthogonality - the ability to change one thing without affecting another. Generally, you get that by moving toward small, focused abstractions.
As another child comment identifies, we should not confuse simple with easy. Clients want easy software, and they have little care or understanding of the complexity. That's OK, on its head, but it is our responsibility to share and teach this side of the software's lifecycle with "management" and "junior" developers. Rich Hickey, author of Clojure, had a great talk on simplicity and easiness of software [0].
[0] http://www.infoq.com/presentations/Simple-Made-Easy