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.<p>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.<p>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.<p>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.<p>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.<p>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.