Less software?

Tilman wonders about 37signals “Less software” approach and concludes that “Less” sometimes is – less!.
Here are a few unstructured thoughts of mine on this very topic:
* The need to integrate a software product in a complex workflow with different, heterogeneous components makes it hard to build “less software”. Interfacing with different machines, different ERP-systems is hard. And complex. Which translates into more, not less software.
* The software 37signals creates is great stuff. The apps work beautifully. However, these are not “mission-critical” apps used by companies to run their core business processes. Plus these apps are very much targeting the “knowledge worker” who’s used to work all day long in front of his/her computer. There are many users out there who don’t want to spend a lot of time in front of their computer & who don’t have the time to play around on their computer. Because they aren’t interested in computers at all plus – more importantly – they get paid to run a business, build real products and face real-world problems. These types of users tend to expect a lot of features with minimum intervention on their behalf.
* You may get away with less features by creating a product which appeals to both tourists & sailors as outlined in Guy Kawasaki‘s The Macintosh Way. However, most likely you’ll end up with powerful software with a great, easy-to-use multi-level UI. To my understanding, that’s not the “less software” approach 37signals is advocating.
However, I still think a lot of the “less software” concepts which came up in the context of 37signals are worth pondering and worth pursuing. Especially if you think about them as related to the well-known YAGNI principle used in XP style software development:

It’s not about anticipating and building what may be needed tomorrow, it’s about building great software for what is needed today.

[Update: Another twist to the topic is that the type of customer I described above wants to pay for features he/she most likely will never use, but doesn’t want to pay for simplicity or ease-of-use]

Comments are closed.