I’ve grown tired of desktop software that gets ever more complex and correspondingly difficult to use. Do we really need all the features and functions being thrown at us? Just because a feature can be added to the software, doesn’t mean it should. Software engineers don’t get paid by the feature.
End users are just as bad. At the start of major projects, they are often like kids in a candy store — they want to try everything. Every user has their favorite feature request. Add them up and you get a long list of requirements — likely too long to be included in a single release. Everyone is focused on what the software does.
Feature bloat compromises software quality. It slows down application performance. It makes the software hard to use. It increases customer support calls and emails. It forces users to buy more expensive hardware. It strains corporate networks.
It’s time to change the focus of software development. Adding more features won’t generate more revenue or reduce customer support expenses. What the software does isn’t the most important aspect of building great systems.
I think that one of the major reasons smartphones and tablets have exploded in popularity is because their apps are simple. The devices are easy to use and they do the things that most people need without all the extra features that they would rarely, if ever, use. We need to focus our software development efforts on the why and how questions.
Two Things Matter
- Business Value: Why does the software contain a feature? Every feature should add value either by expanding the market for the software, saving people time in performing their jobs, or reducing support costs.
- User Experience: How does the business user interact with the software? Smartphones and tablets prove that user experience really matters — a lot.
Such a change in mindset will only happen if business users and software developers work together — side by side. Adversarial relationships won’t help. The best way to get people working together is by using principles outlined in the Agile Manifesto. Please let me know your opinion.