Software Journal

Ms. Juliet Capulet: “What’s in a name? That which we call a rose, By any other name would smell as sweet.” Sure, but Juliet was not an algorithm designer, or a software engineer, or a color guesser!

Apparently, naming is HUGELY important when it comes to those non-romantic fields. John McWhorter’s The Story Of Human Language, presents a fascinating example: people of a certain culture have names for colors red, green, yellow etc, but do not have a name for color blue.  Let us call them NoBluez, and let us call ourselves NoCluez for the time being.  The NoBluez people see colors just fine, just like you and me, but they don’t have a ready name for the color we call blue. On the other hand, they do have two different names for two shades of yellow, that we normally call just yellow.  Let us suppose that their names for the yellows are yellow (the light one) and izaga (the dark one).  An experiment is conducted when colors are flashed quickly, and the people are asked to name the color.  Although the NoBluez people and the NoCluez people are able to name the colors correctly in all cases (they are all home sapiens after all), still, the NoBluez people have a certain delay in finding and calling out the color blue.  NoCluez people, on the other hand, show a delay in calling out the color izaga.  Merely, the naming of the colors, has an impact on how quickly we can recognize it.

Nothing in algorithms, or in software engineering could be a more appropriate lesson.  If you are going to have a fruitful communication with your team mates, and you are going to make sure that everyone understands and uses the newly written method called “processIt(boolean  b)”, then good luck to you!  While you may be able to tell everyone today what the method does, the chances of your method standing the test of a few weeks time, are basically zero.  Someone will write a worse mouse trap, but name it better (for example, “synchronizeCalendars (boolean inclPastEvents)”), and that is the method that everyone will eventually use.

But that is not all of it.  It doesn’t merely affect the usability and recognition of the method. Using a good name helps  the person writing the code or the algorithm as well as you think through the logic and the various components and subsystems.  Especially more so, when you have a system that is bigger than a few lines.  For example, consider the attached MapReduce flowchart (courtesy Lukas).  Naming each of those steps appropriately: “split”, “schedule”, “combine” is helpful in going through the motions of designing.