Verification

It is really irritating these days to come across Web applications that will only work correctly in IE. It is even worse, and rather foolish, for a major organisation to insist on the use of only IE. Users today are no longer on the desktop or on notebooks. It would not surprise me if, even in India, a larger numbers of users are on smart phones!

Even if one only supports IE on a desktop, verifying a website manually just does not make sense, given that there are superb tools like Selenium (http://seleniumhq.org). Once these tools are in use, there will be no lethargy in running regression tests.

Verifying one’s own work is extremely hard—not because we think we are perfect, but rather, we do not notice defects we never intended. We frequently read what we believe we have written, and not what is actually written! On the other hand, verifying someone else’s work is tedious, and may even seem unpleasant. It is hard to keep emotional reactions and personal equations separate from the task of finding defects in code, especially in a facetoface review. However, a couple of applications have made the task of peer reviews much easier. These are Reviewboard (http://www.reviewboard.org/) and Gerrit (http://code.google.com/p/gerrit), which is actually a fork/ rewrite of Rietveld (http://code.google.com/p/rietveld).

The immense benefit of these tools is the integration with source code repositories. Once a code file is modified, one does not need to review the whole file again, but only focus on the changes.

In my biased opinion, the list of tools featured in this article comprises the minimum that those writing software should know, unless they graduated in the previous century. I would prefer it if no one is given a computer engineering or IT degree unless they demonstrate proficiency in this set of tools, or their equivalents. In the long run, those who do not use such tools will be far too inefficient to compete with those who do.