If you think an MVP is the most valuable player in the Super Bowl, you haven't been introduced to the Minimum Viable Product in relation to a software system. Minimum Viable Product, or MVP, is the most basic version of a product that has only enough of the essential features to be marketed. Through this early marketing, the company can glean valuable insight from early adopters, which then guides the development of the fully-featured product. Inevitably, the final product is far better because of that input.
We've all seen it. Applications that are so overloaded with features that what should be extraordinarily simple becomes overwhelmingly complex. This isn't just complicated software, such as Photoshop, which has excellent reasons for its complexity. It's apps that should be relatively easy to learn and use, but aren't, because there are just too many features to make sense of it all. That's feature bloat. Feature bloat hogs unnecessary system resources, adds to the cost of app development, and deliver no incremental benefit. Feature bloat also makes a relatively straightforward app become infuriatingly complicated for some people to use.
Nobody is arguing that there isn't room for improvement in TSA's processes. Anyone who's waited in line for hours upon endless, wasteful, boring, frustrating hours to pass through security and make it to a flight on time knows that there has to be a better way. But the 'cure' the TSA blundered upon is inarguably not that better way.
No matter which niche or industry your business belongs to, chances are you need to purchase software for some aspect of operations. For example, you may need software to handle the finances of your business or to track the results of your marketing campaign. While off-the-shelf software seems attractive, custom software is usually best choice for businesses, as it is developed to meet their specific needs.
There's a common expression "Better to beg for forgiveness than to ask for permission." In the world of software engineering, taking this motto to heart can lead to robust and stable software. Far too often, we try to verify every possible prerequisite before performing an action.