I always thought software industry is the one who figured out ‘convention over configuration’ for doing things in more productive and efficient ways. However, it has been around for ages in other industries. The truth is software development took a little too long to mature to the idea of having it wherever and whenever you can.
Let us check out some real world examples around us where convention solves the problem more efficiently and cost effectively than configuration:
- Traffic lights – From a distance, traffic lights at a big intersection seems to be doing a smart job of facilitating movement of tens and hundreds of vehicles. However, all they are doing is implementing a convention about who goes first and who goes next. Let us figure out what could have been the “configuration” substitute to traffic lights. One could be only allowing few types of movements while forbidding others. This could mean smooth sail for the ones who got the right of way forever while others are left to sulk or start avoiding the intersection forever. Another “configuration” type substitute could be building a couple of flyovers to do away with the need for lights. It will cost a bomb to implement this alternative and will be cost prohibitive for most intersections of the world.
- Railway crossings – implement the right of way of railroad over vehicular traffic. Simple convention avoiding the need for a costly flyover or underpass.
- Assembly line in manufacturing plant – Typically there is a sequence in which a car or machine is put together in an assembly line. However not each of the steps of assembly line may need to be part of a sequence. For some of the steps, it may be a matter of convention so that there is an order and no chaos on assembly line.
So why did it take software industry so long to understand the “convention over configuration” way of doing things. May be because the creative minds were having too much hangover about the flexibility that a software design brings to the table as compared to hardware or manufacturing design. The beauty of software is that it can be modified any number times with only cost incurred is that of labor. The IBMs and Microsofts with their army of developers can redesign and reinvent the same product quite a few times to get rid of technical debts uncovered over a period of time. In other industries, cost of change or modernization is very high as old machinery needs to be disposed of (hopefully in a environment friendly way), and new machinery needs to be funded and brought in, installed, commissioned and so on and so forth.
Therefore the creative minds let us live with extreme flexibility inherent in any software system. However after a couple of decades, the industry realized that too much flexibility leads to half-baked developers sometimes killing mission critical application by making silly experimental changes. Hence the case for enforcing convention.
Convention in software context primarily means a bunch of experts putting their minds together and deciding a set of decent default values for various parameters that would generally work out unless you are in the same league as Google or Amazon or Saleforce or Facebook. For instance, how long an http request should a system allow to survive if the server response is slow. Any usability expert will tell you that if a page is not rendered in 3-4 seconds, you lose the user’s interest. And if the page is not rendered by 7th or 8th second, you lose a customer. Perhaps thousands of such customers.
However, your developers will give so many answers (read excuses) as to why the server slowed down. They might tell you that it was an occasional blip in the network. Or it was an internal ill-timed batch process momentarily eating up all the resources. Whatever it was, you lost some customers. Had you put in a convention that a slow response would mean switching the request to another server no matter what, it would have saved your reputation and revenue. There are zillions of Google searches that occur every day, not one of them comes back with http 404 or http 500 error. Even in situations when there is no network, Gmail keeps the user engaged by hinting the user to read emails already present in his/ her browser and not worry about lack of network. Apple Corporation always ridiculed the words “upgrade” and “peripheral” used frequently by Microsoft as Steve Jobs believed that end users don’t deserve the tortures of software upgrades and the ordeal of looking for the right drivers for the various components attached to a Mac computer.
Just some simple out-of-the-box “convention” driven thinking where you don’t start looking for technical reasons of failure but find alternatives to handle failure scenarios.
Software industry still has to go miles on “convention over configuration” route. However there are some encouraging developments that are worth mentioning. Most browsers and other softwares ship with “auto update” options for automatic version upgrades. If you like tinkering with Linux, then all you need to do to install a new piece of software is just issue one command (called yum install) without worrying about where to get the software in question. For instance,
“yum install tomcat7” will install Tomcat ver 7 and “yum install mysql” will install MySQL.
What are your thoughts about “convention over configuration” and its applicability in your IT infrastructure? Do you sometimes tell customer that the server is running slow so you can’t service them at the moment or you have alternate ways of handling such situations. Share with us.
Explore the mainstays of mobile integration and ways to integrate mobile apps in your enterprise. Click the image below to download the whitepaper -