Convention over Configuration
January 30, 2007
Of late I have been quite intrigued by some analysts reports on IT becoming a commodity service. By being a commodity, it no longer appears intellectual or elite.
The driving forces – cost, expected higher productivity, competition, e.t.c.
We view and judge programming languages and platform by the amount of flexibility that they provide. This explains the umpteen number of configuration files that our applications have these days. After all we have been taught to “externalize” as much as possible, out of the application code – the reason : maintainability and flexibility.
But havent we taken it a bit too far? How often do table and column names change for e.g? Can we instead agree on conventions for a few of these instead. Why conventions? Because it opens many exciting possibilities around creating or using frameworks to do a lot of work for you. A great example is the Ruby On Rails(RoR) platform. Iam not endorsing RoR here. I however like its idea of being able to do so much behind the scenes because the application artifacts – tables, classes follow convention. Coming to think of it – we do enforce conventions, dont we?
So why not create the conventions ins such a way that it can benefit us, the developers, and not just some standards watch dog? Eventually everybody benefits – the developer writes less code, the project is done cheaper, developers are seen as being more productive, cost comes down e.t.c
Get what Iam driving at? I seriously feel that the comments in the early part of this post will become a reality. We just need to be able re-define the way we do things – one such is adopting “Convention over Configuration” and building intelligent frameworks on top. I see RoR doing that.