For a long time, software has been measured and marketed on the basis of features. Ever increasing feature lists have arguably been the life-blood of software upgrades for at least the past decade.

Though obscured by the hype, one valuable aspect of the Web 2.0 phenomenon is a backlash against such feature-laden software. For the sake of convenience, I’m going to call this idea “feature frugality”.

Feature frugality should be a critical consideration for all software developers. Why? Because every feature carries additional cost, and that cost must have some corresponding benefit for the end user.

What does an additional feature cost? Well, most obviously, they cost development time. They also cost requirements definition and QA/testing time. Then there’s time supporting users when there are inevitably bugs in the code written to implement that extra feature. Even ignoring bugs, there is additional time to adequately document how to use the extra feature and perhaps even teaching or training users.

With all that investment of time and money, the need for there to be a benefit for users should be self-evident. Keep in mind, however, that it can be valid for the end-user benefit to be indirect: e.g., a feature that (ethically) gathers metrics on user interactions might not have any direct and immediate benefit to the user of the software, but might help a company better understand how people actually use their software, and allow them to focus their development efforts on better supporting common tasks in future releases.

The bottom line is that features need to earn their place in a product. Developers and software companies need to carefully consider and be able to justify the inclusion of each and every feature in their software.