In his book Steal Like an Artist, Austin Kleon makes this insightful statement:

In this age of information abundance and overload, those who get ahead will be the folks who figure out what to leave out, so they can concentrate on what’s really important to them. Nothing is more paralyzing than the idea of limitless possibilities. The idea that you can do anything is absolutely terrifying.

This resonates nicely with another article here on frugal engineering or “designing more with less”. In this article the authors (Nirmalya Kumar and Phanish Puranam) discuss how innovation is meeting the needs of the Indian marketplace, where consumers are both demanding as well as budget constrained and how “the beauty of the Indian market is that it pushes you in a corner…it demands everything in the world, but cheaper and smaller.” This article also talks about “defeaturing” or “feature rationalization”, or “ditching the junk DNA” that tends to accumulate in products over time.

As an example of this the most popular mobile phone in India (and in fact, at one point, the bestselling consumer electronics device in the world) is the Nokia 1100. The reason for this device’s popularity? Its stripped down functionality (ability to store multiple contact lists so it can be used by many users, ability to enter a price limit for a call and built-in flashlight, radio and alarm) and low price point make it an invaluable tool for life in poor and underdeveloped economies such as rural India and South America.

For a software architect wishing to make decisions about what components to build a system from there can often be a bewildering set of choices. Not only do several vendors offer solutions that will address the needs there are often many ways of doing the same thing, usually requiring the use of multiple, overlapping products from different vendors. All of this adds to the complexity of the final solution and can end up in a system that is both hard to maintain as well as difficult, if not impossible, to extend and enrich.

Going back to Austin Kleon’s assertion above, the trick is to figure out what to leave out, just focusing on what is really important to the use of the system. In my experience this usually means that version 1.0 of anything is rarely going to be right and it’s not until version 2.0+ that the fog of complexity gradually begins to lift allowing what really matters to shine through. Remember that one of my suggested architecture social objects is the Change Case. This is a good place to put those features of little immediate value, allowing you to come back at a later date and think about whether they are still needed. My guess is you will be surprised at how often the need for such features has passed.