Before Jeff Goldblum found fame and fortune with the Jeff GoldBluMan Group, he was in a little movie called Jurassic Park.
In a film about resurrecting dinosaurs his character had this to say:
'..your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should.'
Another pop icon, Patton Oswalt, made a similar point about mans' desire to pursue 'could' over 'should' (he describes the miracle of child birth by a 63 year old woman in graphic detail).
We shall call this the Goldblum Oswalt Syndrome (GOS), whereby you do something because you can, not because you should. There's some awesome advice that you can take from the GOS if you apply it to the world of App/Software Design. We often add features to an application because we CAN, not necessarily because the application NEEDS it.
Let's say you're building a web application that needs a sign up page, and you're sitting around discussing what fields should go into it. Someone suggests adding a 'Title' field. You (the Developer) answers:
"Yeah, I CAN do that".
Maybe you're new to the company, you're eager to please, maybe you can't think of a good reason why the customer record SHOULDN'T have a title record. What harm could it possibly do to add that one little piece of functionality?
1) Extra features mean more user interface
Typically when you add a new piece of functionality, you have to add some way for the user to interact with it. This can mean a host of new problems including: more clutter, more complication, more chance for confusion.
That tiny little title field - that means a new drop down on the form when signing up - and another thing for the user to have to think about when using your application (for more info about great user interface design see the book "Don't Make Me Think").
2) Creating things always take longer than you think
Developers are an arrogant species, full of hubris and inflated sense of their own skills. "Sure I'll add that extra piece of functionality," they'll tell you, "it'll be done in before lunch." They mean well, but unfortunately 9 times out of 10 adding even the simplest piece of new functionality will take significantly longer than expected.
But how hard could it be to add that "Title" field be you ask? Well, does it require validation? Should the title be included with the full name of the user? All of these questions require exploration, which normally only takes place once it becomes a requirement that you didn't realise you had.
3) Extra functionality means more code
Most of the time, new functionality means more code. More code for developers to wade through, and to understand. More code means something else that a developer has to keep in their head when they're working on something related. This can also mean more chance for new bugs, meaning more time spent on fixing bugs.
4) Opportunity cost of doing something more useful
Opportunity cost is a basic economic term to describe the loss of the value of the next best alternative as a result of making a decision. For example, if you buy a bag of crisps for ¬£1, an opportunity cost could be that you could've bought 3 apples for that ¬£1 instead. In a nutshell, one thing always come at the expense of another.
The time spent on a feature that you merely CAN do rather than SHOULD do is not just wasted time, you've basically also lost time that would've been better spent on doing something useful. Instead of adding the title field to the User record, the time could be spent on making sure the billing process works.
5) You ain't gonna need it
And you know what, chances are that new piece of functionality that you CAN add - it's probably not even going to be used!
What would you be using the title field for? Why is it necessary? Are you adding any value to the application/user experience? Or are you adding time until you get a release out that has real-world feedback.
I know it's hard to say "no" - but as you can see, working on features simply because you CAN is not a great idea.
Each feature should have to fight to get into your application, it should go through a trial of fire. Then when the application is complete it should only include those features which are absolutely required, and not have any unnecessary features. A feature should NEVER be added to an application simply because it COULD be added.
So, take Jeff/Patton's advice: next time you're adding a feature to an application simply because you can, stop..and think about whether you SHOULD.