Joel has said in the past that nothing has increased sales more than adding new features. I've always wondered how he reached that conclusion and what data he used to arrive at that. (it doesn't necessarily follow that if subsequent releases generated more sales and had more features, then it's because of those features that sales were made).
Generally I've found that simplicity may not create marketing buzz for your product but will result in more people actually using it (sadly people using != more sales all the time). That's why people still use excel instead of the enterprise crm/erp system that their COO bought.
The comparison is between improving the product and traditional marketing. We found, over and over, that improving FogBugz (sometimes by adding new features, but not always) was much better at increasing sales.
Recently, that's begun to change somewhat, mostly due to patio11 coming around periodically to tell us everything we're doing poorly in our marketing.
From the end user's perspective, features often reduce complexity, sometimes dramatically so. Before "mail merge" was a common MS Word feature, collating form letters was a tedious job.
Good engineering and design integrates features into the application in a way that avoids complexity.
This was implied by Duff's use of the word "necessary" [sic]. I believe his point was that it's possible to have features and complexity.
So although you're right that providing both simplicity and feature-richness is not free, the companies that can afford both (assuming the features address actual problems, or even just pain points, that customers have) are going to fare better than those that don't.
I have found the recent trend of lets "simplify" everything cause Apple did it at times annoying. Take for example the Gnome 3 shell. Most Linux users want "options" and don't mind complexity otherwise they would buy a Mac.
I find it ironic that Apple has prided itself with "Think Different" and break away from big brother (for those that remember the "1984" commercial) when apparently Apple prefers homogeneity instead of uniqueness.
> I find it ironic that Apple has prided itself with "Think Different" and break away from big brother (for those that remember the "1984" commercial) when apparently Apple prefers homogeneity instead of uniqueness.
The 1984 commercial wasn't intended to state that every individual computer should be different, but that you should be able to do different things with your computer than just the business applications that were prevalent.
Actually I wasn't really focusing on their software but their hardware (my wife wants the iPhone in gray to match her coach pocketbook). You can actually customize Mac OSX far more than you can customize gnome shell.
I was merely making fun of Apple's crazy licensing for the App Store, their lack of respecting privacy, the fervent fanatic love for them, and that a majority of the users that use Apple products are of a particular demographic all of which to me is very very 1984ish.
It's a little more nuanced than that. The simplicity enabled many more people to express themselves in contexts other than spreadsheets. The Macintosh, for example, ushered in the age of desktop publishing, which was a boon to writers and academics.
Practically speaking, I don't see that as having changed in Apple. They still see the gateway to creativity and self expression being ease of use, as opposed to some other values such as hardware compatibility or UI customizability.
"Simple" means different things to different people.
Apple aims their products at individual people. "Think Different" means "Don't think about your computer". So write your book, keep your spreadsheets, whatever. The user doesn't care about the computer.
Microsoft, in contrast, wants to keep the CIO happy. So you have robust single sign on, reliable and modular patching capability and backwards compatibility. IT cares about the computer.
Open source projects are all over the map. In general, current Linux users are enthusiasts. They WANT to customize Emacs macros and tweak their operating environment. The user cares deeply about the computer, and gets some amount of joy out of futzing with it.
The apple comment was merely tangential observation. My concern is people using "Simple" as an excuse to not deliver. Just like we use different dialogue for different audiences we build software for particular audience. Gnome Shell is not Linux Users.
Your interpretation of "Think Different" is nice but I don't think its what Apple was thinking. In fact it seems Think Different was stated as "there are other alternatives to the PC".
Later on Apple reused the phrase to indicate that they are creative paradigm shifters and in the same league of some one who topples a regime when in a reality they are now the regime/status quo.
But all else being equal wouldn't you prefer "simple" options to complex if in the end they achieved the same thing? Simplicity is not necessary limiting yourself to only simple results, it is being able to do what the user wants in a clean, elegant, intuitive way.
>>Most Linux users want "options" and don't mind complexity otherwise they would buy a Mac.
We are existing Gnome users. We want the features we have built work habits around. I went KDE rather than Unity and am quite happy so far.
If I started to use an Ubuntu system now, I'd probably like Unity.
Apple plans their users' learning curve/experience, so we find things out after a while. Same thing as what [edit: Ubuntu tries to do with Unity], I'd guess.
"""Most Linux users want "options" and don't mind complexity otherwise they would buy a Mac."""
The problem is that they do buy a Mac. In droves.
Also Gnome wasn't targeting "most Linux users", but those that valued a simple (Mac like if you want) UI. And also "non Linux users".
"""I find it ironic that Apple has prided itself with "Think Different" and break away from big brother (for those that remember the "1984" commercial) when apparently Apple prefers homogeneity instead of uniqueness."""
Ironic how? Who said homogeneity contradicts uniqueness? You can offer stuff unique --compared to what others sell--, and have it be homogeneous in your product line, at the same time. The difference lies in how you go about creating those products, not in that they differ between themselves. I.e true difference is in the iPhone vs a Nokia phone, not in the 200 versions of Nokia phones available.
I almost completely disagree. To be fair, I don't doubt that there are companies use simplicity as an excuse for not adding value. At the same time, there are at least as many companies out there that pack feature after feature into their products, then find themselves asking "Why is no one using my product? It can do so many things!"
The fact of the matter is that simplicity is a value. I suppose one could argue that it's a somewhat overrated value. But for startups, it's the most important value. Startups simply don't have the time or resources to create complex products, at least starting out.
I think what Joel argues that you can keep things simple but keep adding features. Granted that's really hard to keep the balance but it's doable. Simplicity is hard, keeping it simple while adding new features is even harder.
> Startups simply don't have the time or resources to create complex products, at least starting out.
Completely agree. It's one of the easiest things that a startup can provide (assuming there's talent within the company who can deliver that simplicity. All developers know by now delivering simple and usable software can be really hard)
I think it depends on the market. There are some markets where complexity is really a pain. There are other markets where existing products are already simple enough for the given users that this is not the main concern.
Unfortunatelly in markets where complexity is a huge pain nowadays it is very hard to find or build the relatively simple solutions. Otherwise others would have found/built it already.
So yes, yet another bug tracker will not win in the market just by being even more simple than the other simple bug trackers.
But in a market where users are actually fustrated of the complexity they have to deal with - it can hit big. For example in case of programming languages, frameworks it is a big selling point to be simple: programming can become fustratingly complex if the tool is not designed with simplicity in mind (see enterprise Java). That's why things like Ruby on Rails are successful.
A better title might be "simplicity is used as an excuse for creating worthless software."
But anyway, Spolksy basically advocates finding the "elegant" solution, which is the one that incorporates useful features in an easy-to-use way. Hardly a controversial position. However his use of the word "simple" consistently conflates feature-poorness (lack of features) with ease-of-use. So when he says focusing on simplicity results in worthless software (as indicated by actual sales), he appears to attack ease-of-use. He's not. He's only attack feature-poorness. Cue confusion and controversy.
Simplicity and features are related, but they aren't opposite ends of a spectrum. I tell my design and product team that as the core feature set grows, more development time and design effort must be invested in keeping the software simple to use. Similar to the way your test suite must grow more powerful to cope with increasing code complexity. There's probably a cool metaphor like technical debt lurking around here somewhere.
As an example, think of Facebook - one of their ideas was to simplify the standard classes & permissions system down to concept everyone would understand and use: Friends. Friends is basically permissions without the classes, wrapped around a familiar mental model. This was very successful, but over time users demanded the ability to grant different permissions to different users. For example, family vs. applications or close friends vs. co-workers.
So Facebook re-introduced the concept of classes to their permissions systems. They called them lists. And they ran into the same problem that has bedeviled permissions systems from the dawn of Unix. It's a PITA to understand and manage the additional complexity.
So Facebook invested a lot of time in simplifying class management. Namely, they used social signals, some basic heuristics (everyone has a class called "applications" and another called "family") and probably some other information to auto-assign friends to classes for you.
While the new, class-aware permissions system is more complex than what Facebook started with, it's simple enough that users seem to be adopting it just fine.
This is just one example, but this sequence is repeated everywhere good software is made. And it's pretty easy to understand: stop adding features when they add too much UI complexity for your target audience to successfully use. Assuming you're not doing monolithic releases and are capturing lost of user feedback, you'll know when you're about to cross the line.
> While the new, class-aware permissions system is more complex than what Facebook started with, it's simple enough that users seem to be adopting it just fine.
Do you have a reference for this? In my personal experience, very few people are using the new list feature.
3) Next gen comes along and builds a simple variant with only critical features
4) Feature creep
5) back to 3
It's human nature to want to 'improve' something. With software that invariably means more features. New managers/owners of any project usually arrive with a shopping list of improvements - because more features = happier customers right?
I'm not sure I'd want advice on the value (or lack) of simplicity, from someone who is in part responsible for Visual Basic, and has two main products that are far from either top notch or tremendous financial successes and which are coded in a monstrous ad-hoc compiler that spits out PHP and/from ASP.
That said, he has written several good project management essays --if you skim though all his bullshit UI and interview advice. I mean, UI advice from the man responsible for CityDesk??!
Well, at least you can't fault his very good mercurial tutorial, or Stack Overflow.
It may be popular to hate VB, but it was certainly much simpler to develop with than the C++ Windows SDK was at that time. Surprisingly powerful too. I remember building both a point/click adventure game , a poker game and an organizer app from scratch without any formal CS education.
From what I remember Joel was responsible for VBA, which brought programming to people who had no idea what a pointer was. Of course this spawned some of the most badly written business apps out there, but that's hardly his fault.
Are they still using their own compiler? Never really understood the reasoning behind that , I believe it was to make it compatible with Windows and Unix, but surely they could have simply written the app in php and bundled it with apache all statically linked together?
Pherhaps CityDesk was not the best thing ever, but nobody gets it right every time.
IIRC they wanted to make an existing ASP app (FogBugz?) and be able to sell it to Unix shops, ergo a cross-compiler that spit out PHP from ASP. They did not want to maintain two distinct codebases. From that, it evolved into an in-house bespoke development language.
Also IIRC, in its day CityDesk was a fair bit simpler than other website management systems.
Generally I've found that simplicity may not create marketing buzz for your product but will result in more people actually using it (sadly people using != more sales all the time). That's why people still use excel instead of the enterprise crm/erp system that their COO bought.