One of the best ways to keep an app simple is, of course, to limit how many features you implement. Twitter, for example, has very few features, but is enormously successful. The limited number of features of Twitter make it really easy to keep the application simple, which lets the developers focus a lot on the quality of the system, the polish of each individual feature, etc.
Twitter’s just one of the many proofs that you don’t have to have lots of features to be successful. In fact, many successful apps have fewer features than their less-successful competitors.
Still, you’ve got to have some features. 🙂 After all, it’d be pretty silly to be programming, otherwise. But how do you decide which features you should have? Is it just up to the Chief Architect’s intuition, or how many users demand that you give them “feature X”? Does whoever shouts the loudest in the development meeting get their feature implemented first?
Well, no, there is a way to decide whether or not you should implement a feature, and it comes out of one of our most basic principles: the purpose of software. This principle (that the purpose of software is “to help people”) isn’t just some fancy-sounding gibberish I made up to make myself happy–I wrote it because it’s something that can actually be really useful to think about in everyday programming, and this question of “Should we implement this feature?” gives us a great opportunity to show how it can be applied. Keep Reading