Why "Simplicity Works Everytime"
Some explanations on the title of this blog...
From my work in delivering, designing, and developing high-performance financial systems, I have been struck by the fact that the most usable, most loved (yes that is possible), best performing, and highly scalable systems have simplicity as their underlying theme.
Now simplicity can be a highly subjective topic. So let me clarify what I mean...
You can broadly classify any system into one of these two categories -
1.) A User-Driven System. This is any system with a customer-facing user interface. (Technical support user-interfaces do no count here)
2.) A Technical System, i.e. a non-User-Driven system. This could be a server process that runs independently of any customer interaction.
In the presence of competition, the success of a user-driven software application is a function of how much the customer likes/loves using it. This is exponentially proportional to it's the ease of use. For most users, software is just a tool to get some work done. It is not a primary part of their existence. Users love software that allow them to finish their task with the least amount of thinking so that they can focus on the really important things in life. So for user-driven software, simplicity equates to "simplicity for the user", not "simplicity for the developer". In order to provide this simplicity to the user, the underlying technical design might have to be complex, very complex. Sorry, there is no way around this.
And finally, user-driven software attain the nirvana of simplicity when they become humane. These software forgive our human follies, and guide us ever so subtly in our tasks.
Let me tell you why I absolutely love iTunes. It has this great feature called "alphanumeric sorting". In layman's terms, this means that a song titled "Eagles - Track 10" will come after "Eagles - Track 9", and not "Eagles - Track 1" as happens in Windows Media Player. iTunes also has another amazing feature where they discard the word "The" in the band name during sorting. So "The Cardigans" comes under C, not T.
For pure technical systems, things are different. The best technical systems have very very simple technical designs. Great technical systems do not have highly normalised data schemas; Simple technical systems are not in love with their reflection; Simple technical systems actually hardcode things that will never ever change; Simple technical systems do not try to retrieve data using humongous object-relational mapping layers; Great successful systems mostly never use EJB's; Great systems solve one thing very well.
In DB, we bought a 3rd-party scheduling software that used 90 Oracle tables internally for managing clustering. The thing bombed in actual production usage. An internal team rewrote the same functionality with some simple code that used 9 Oracle tables for managing a load-balanced cluster. It is so successful that other teams in DB are using it, and we are thinking of making it open-source.
The problem is that as an industry, we have completely lost the concept of simplicity. We have become experts in abstracting any user request into a generic problem, and spend ages building generic systems that look great to us in our mental sheet of paper, but hideously complex at runtime. We have forgotten that software is actually about working applications. Instead of solving user problems, we have all become self-anointed architects.
One of the sidey things I will be doing thru this blog is to keep up a steady stream of views and observations on keeping things simple.
"You know you've achieved perfection in design,
Not when you have nothing more to add,
But when you have nothing more to take away"
~ Antoine de Saint-Exupery
From my work in delivering, designing, and developing high-performance financial systems, I have been struck by the fact that the most usable, most loved (yes that is possible), best performing, and highly scalable systems have simplicity as their underlying theme.
Now simplicity can be a highly subjective topic. So let me clarify what I mean...
You can broadly classify any system into one of these two categories -
1.) A User-Driven System. This is any system with a customer-facing user interface. (Technical support user-interfaces do no count here)
2.) A Technical System, i.e. a non-User-Driven system. This could be a server process that runs independently of any customer interaction.
In the presence of competition, the success of a user-driven software application is a function of how much the customer likes/loves using it. This is exponentially proportional to it's the ease of use. For most users, software is just a tool to get some work done. It is not a primary part of their existence. Users love software that allow them to finish their task with the least amount of thinking so that they can focus on the really important things in life. So for user-driven software, simplicity equates to "simplicity for the user", not "simplicity for the developer". In order to provide this simplicity to the user, the underlying technical design might have to be complex, very complex. Sorry, there is no way around this.
And finally, user-driven software attain the nirvana of simplicity when they become humane. These software forgive our human follies, and guide us ever so subtly in our tasks.
Let me tell you why I absolutely love iTunes. It has this great feature called "alphanumeric sorting". In layman's terms, this means that a song titled "Eagles - Track 10" will come after "Eagles - Track 9", and not "Eagles - Track 1" as happens in Windows Media Player. iTunes also has another amazing feature where they discard the word "The" in the band name during sorting. So "The Cardigans" comes under C, not T.
For pure technical systems, things are different. The best technical systems have very very simple technical designs. Great technical systems do not have highly normalised data schemas; Simple technical systems are not in love with their reflection; Simple technical systems actually hardcode things that will never ever change; Simple technical systems do not try to retrieve data using humongous object-relational mapping layers; Great successful systems mostly never use EJB's; Great systems solve one thing very well.
In DB, we bought a 3rd-party scheduling software that used 90 Oracle tables internally for managing clustering. The thing bombed in actual production usage. An internal team rewrote the same functionality with some simple code that used 9 Oracle tables for managing a load-balanced cluster. It is so successful that other teams in DB are using it, and we are thinking of making it open-source.
The problem is that as an industry, we have completely lost the concept of simplicity. We have become experts in abstracting any user request into a generic problem, and spend ages building generic systems that look great to us in our mental sheet of paper, but hideously complex at runtime. We have forgotten that software is actually about working applications. Instead of solving user problems, we have all become self-anointed architects.
One of the sidey things I will be doing thru this blog is to keep up a steady stream of views and observations on keeping things simple.
"You know you've achieved perfection in design,
Not when you have nothing more to add,
But when you have nothing more to take away"
~ Antoine de Saint-Exupery
No comments:
Post a Comment