Software engineering recommendations have not changed. The issues and concerns have been known for years. However, with the availability of excellent tools, it is no longer a pain to implement and follow the recommended practices, starting with the requirements analysis.

Getting started

Requirements analysis phase is perhaps the most important activity in the impact it has on the success of a project. It is also the most amorphous. A software engineer should be able to organise his thoughts and analysis in a manner that it is clear to the team. He should be able to communicate his understanding to the customer or user to be able to get appropriate feedback.

Freemind (http://freemind.sourceforge.net) or similar memory map tools can be invaluable for both these needs. The tree-structured presentation is very concise, making it easy for people to comprehend the whole picture. Furthermore, it allows one to easily expand each branch to view more details selectively. The use of tags and notes allows the mind to focus and not be overwhelmed by the excess of data. The one issue that may be a challenge is to get an organisation to add memory maps as an acceptable way of communicating the requirements.

The requirements need to be converted into an estimate of effort and time. There is also a need for a plan. A useful tool for these cases is Planner(http://live.gnome.org/Planner), which is included in most distributions. I personally had liked faces (http://faces.homeip.net) very much. It still is worth exploring even though it has been a dormant project for the last few years. It appealed to me as the plan is Python code and, as a consequence, making changes in the plan was incredibly simple! While it may be hard to get an organisation to use faces, a programmer may find even planning fun using it.

Execution

A second part in project execution is keeping a track of the status of the project. For this activity trac (http://trac.edgewall.org ) is a wonderful tool which combines a wiki with a ticketing system. The ticketing system is invaluable in keeping track of tasks, issues and change requests.

Trac includes the ability to browse the source from a subversion repository. Needless to say, a plugin is available for trac for browsing a git repository as well.

Subversion (http://subversion.tigris.org) and Git (http://git-scm.com) are great options for keeping the source in a repository and ensuring that all changes are tracked. It is rare to find a programmer who has not needed to undo the changes he has made and has to make a substantial effort to trace the changes. There is really no excuse for not using a source code repository these days.

The excellent integration of unit testing tools with IDE's makes it very easy to code unit tests as a part of the programming activity. Each software engineer should be familiar with the java JUnit or a unit testing framework for his preferred language(http://en.wikipedia.org/wiki/Junit) . Martin Fowler's comment about JUnit says it all: "Never in the field of software development have so many owed so much to so few lines of code."

Verification

It is really irritating these days to come across web applications which will work correctly only in IE. It is even worse, and dumb, for any major organisation to insist that the user use IE only. The users are no longer on the desktop or notebooks. It would not surprise me if even in India larger number of users are on smart phones!

Even if one is only supporting IE on a desktop, verifying a web site 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 ones own work is extremely hard. Not because we think that 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 face to face 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 above list of tools is the minimal set any person writing software should know, unless he graduated in the previous century. I would prefer if no one is given a computer engineering or IT degree unless he demonstrates proficiency in these set of tools or their equivalents. In the long run, however, those who do not use such tools will be far too inefficient to be able to compete with those who do.