Remove features, don’t add them!

There seems to be something about programming that makes software engineers seek the perfect solution to a given problem or design brief.

Something that drives them to keep adding things to their program or library until they kill it with love for example Microsoft Word has a gazillion features but until recently (its has improved a bit) the GUI which is the main component of the program the user uses was horrendous to use and you could not locate most of those extra features easily.  This death by love seems to manifest especially consistently during framework, library and API development.  There seems to be a burning desire in every software engineer to make every library so generic it can solve any problems, not just what it’s design specification demands.

It is very rare to hear of a program, library or framework being criticised for doing too little or being too simple.  Usually the criticism is about the program or library being too bloated, too stuff full of features and love to be easy to use.  This criticism is so common and yet every day bloated libraries and applications are released.   It is rare and pleasant thing to discover a small concise application, library or framework that solves its problem domain excellently and no more.   In fact I can only think of a few examples:

• SQLite is a C library which implements a compact, fast and efficient SQL engine, take a look at the list of companies using it, as well as all the open source wrappers available for it in most major modern programming languages.  This library is a study in minimalism, it does only what is required to meet its design goal with no surplus frills or bling.
• DropBox is an online service with client applications (for PC and Mac) that provides file storage and synchronisation across multiple computers and operating systems in a refreshingly simple and efficient manner.  I was stunned to see how easy to install it was and how few configurations options are provided (hint: few are required by the client as it works out what it needs).
• Google‘s search engine really needs no introduction.  Take a moment to look at the Google homepage and compare it with Yahoo!‘s or MSN‘s homepage: Google’s hompage is a study in simplicity compared to Yahoo!’s or MSN’s homepages.

I think I can best explain this by a talking about model making: as a young lad I used to spend hours building and customising Games Workshop miniatures which I used to collect and play war games with.  I got to the point in my teens were I was pretty good at the building, customising and painting of miniatures and won a few awards in local model competitions.  I can’t remember when it happened but I remember coming to the realisation one day that there is such a thing as too much customisation, building or painting and that it is very hard to know when to stop without first ruining a few models.  Later on I remember thinking about this concept some more and realising that this is applicable during just about any creative design work e.g. painting, gardening, music, programming etc.  Think about what would have happened if Leonardo da Vinci had kept adding brushstrokes to the Mona Lisa, would we still know who he was?

The key I believe is not to think ‘what can I add’ but to think ‘what can I reduce (simplify), refactor or remove’ from my design while still meeting my design brief/requirements.  As many compact, efficient libraries with concise, simple APIs can be combined in many more flexible and powerful ways than a few monolithic ‘kitchen sink‘ libraries with massively complex APIs.

In a nutshell: figure out your solution, then refactor and simplify it down until you meet your requirements in the simplest possible manner.