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.
So, let’s say that the purpose of your software is “to help people learn to type,” and you have to decide, “Should we add New Feature X?” Well, here’s what you can ask yourself about the feature: “Does this help people learn to type?” Simple. 🙂 If the answer is no, then you don’t implement the feature. Also, “Does this harm people learning to type, or get in the way of learning to type?” If it harms people more than it helps them, then it shouldn’t be implemented.
Now, quite often, you’ll find that you can’t really say whether or not a proposed feature actually helps your users (or helps them more than it hinders them). You can’t stand there with certainty and say, “Yes, this absolutely helps people learn to type.” In that case, just skip it. Don’t implement the feature. There are plenty of features out there in the world where you can be sure that it will help your users–implement those instead. Perhaps some more data will come along in time that will make your decision clearer about this uncertain feature, but until then, you don’t have to implement it. Just wait (or go collect data to make your decision easier).
This whole idea is also very handy for prioritizing features. You ask yourself, “Out of all these features, which ones will most help people learn to type?” That sounds perhaps like an overly-simple suggestion, but I think that for Bugzilla, if we really looked at all our requested features and said, “Which one of these will most help people track bugs?” we’d come up with a pretty good priority list, and probably have some interesting discussions, too.
The higher you set the bar for certainty on these questions, the fewer features you will have, and the simpler your application will be. That is, you could say, “We have to only be kinda certain it will help people,” and that’s your standard (or “bar”) for helpfulness. Or you could say, “We only implement features that we are totally certain will help people,” and you’d probably have an enormously simple and very well-designed application. But it’s a judgment call–sometimes it’s hard to get data, and you have to implement features that you’re only pretty sure will be helpful. That can be the right decision, though, sometimes–different situations require different solutions.
Overall, how you make these decisions is up to you. What really matters is that you ask the questions. That’s one of the keys to keeping your product focused, simple, and polished.
Did you seriously just use Twitter as an example for quality? It’s most famous for the “Fail Whale” and insane amount of unpredictable downtime… I hope Mozilla isn’t aiming to use Twitter as an example for anything how *not* to manage a project. 🙂
Yeah, what Havvy said below–I was talking about simplicity and the quality of individual features.
Twitter’s downtime problems are a scaling issue–the result of some backend decisions that was made incorrectly at the beginning of the project.
@Craig: So it goes down unpredictably. Uptime wasn’t key to the essay. Simplicity was. Though, I guess, adding Uptime as a feature would help it. 😛
Very astute observation. I hadn’t thought about simplicity of features coinciding with the success of a program before. That’s very true.