Karachi   ->   Sweden   ->   Karachi, again   ->   Dubai   ->   Bahrain   ->   Karachi, once more   ->   London and Leeds

Sunday, March 29, 2009

What's in a name?

Everything.

Its narrated in Quran (Sura Al-Baqara, 30-34) that Hazrat Adam (AS) was taught the "names of all things" and when the angels enquired why humans were selected as caliphs on Earth, Allah asked the angels to narrate the names, in which they failed. Then Allah instructed Hazrat Adam (AS) to tell the names, which he did.

I was always intrigued by the phrase "names of all things." Below is what my pursuit has led me to. Please note that I am not trying to interpret Quran here, just the phrase, "what's in the name?"

Those who know not are not capable of achieving same results as those who know. And to know is to be able to "identify" and to "associate." Lets compare a person for whom all mobile phone devices are just "mobile phones" to a person who can tell a "Sony Ericsson" from a "Blackberry." Even more is the knowledge of a person (regarding mobile phones) if he can tell a "Blackberry Curve" from a "Blackberry Bold." So, being able to tell the names of things is actually "knowledge."

If this example doesn't make sense, you can fit in anything that interests you---be those mobile phones, type of internet connections, etc.


Quite interestingly, I have found that a lot of mayhem ensues if you can't name things you create yourself. While this can make sense for any creative work (music, movies, painting, etc.), this is typically true for versions of software you create. Let's assume that you are not versioning your code, and you are making changes every now and then, creating new binaries. If there is no way to tell one "version" from another, you are bound to
  • fix bugs in more than one places
  • fail to properly upgrade one system to a newer version when required
  • while seeing a binary, you can never tell what it does
I have heard programmers saying, "Yes, this is a known bug in the release prepared by coder X in 2008 but it was fixed by coder Y in the same year. Why don't you get the release from coder Y?"

Lost efficiency! And lots of headaches! Just name your versions and see the wonders. Remember: to version your code is to able to "identify" one release from another, and thus "associate/ disassociate" features/ bugs with releases.