Log in ....Tribune


Dot.ComLatest in ITFree DownloadsOn hardware

Monday, May 27, 2002
Article

Bitten by the programmersí bug
Ankur Gupta

BUGES are a programmersí nightmare, an ordeal that every programmer has endured. Howard Aiken of the Harvard University coined the term Bug. One of his programs did not run properly due to a moth short-circuiting the computer. The moth or the Bug tends to creep up when you least expect it to. So the obvious question that comes to mind is: Can bugs be prevented?

Taking an analogy, in the seventies, American auto manufacturers were plagued with quality issues because they assumed that defects were an inevitable part of production. They tried to solve the problem by dealing with defects at the end of the assembly line. A large amount of resources were being consumed diagnosing the cause of every problem found, then removing each problem. On the other hand Japanese auto manufacturers, who were experiencing similar difficulties, chose to take a different path. Rather than attempting to improve product quality by fixing defects at the end of production, they attempted to prevent defects from being introduced during production. This approach discovered the root of the problem by determining where, why, when and how defects were introduced and devise strategies that would prevent the introduction of each defect.

 


Bugs are introduced as a result of human error. So if you take proper precautions, Bugs can be prevented. Currently, the trend in software development is to produce code as quickly as possible, then extensively test and debug it towards the end of the development process. So the next question that arises is - Does the time tested saying "prevention is better than cure" hold good in this case too?

So how exactly can coding Bugs be minimised or prevented. Well, Bugs are results of programming errors. There are "exciting programmers" and "dull programmers". The "exciting programmers" are the ones fixing the showstopper bugs. When they have time to come to the all-project meeting, all eyes are on them. Will they be the "hero" once again? Will they rescue the maiden of the product? The "dull programmers" always come to the project meeting, but no one ever pays any attention to them because their code is not in crisis. Here are some programming practices one should follow if one aspires to be a dull programmer:

1. The fundamental rule for good programming is to develop programming guidelines, which have to be religiously followed. Programming guidelines are often tailored to the needs of projects but certain specifications such as using descriptive variable names, ample comments are always present.

2. It is always a good idea to divide the code into functions with each function doing a specific job. Each function used should be tested independently and thoroughly. Any undetected error in an oft-used function can plague all parts of a program.

3. Backing up code that has been tested is important, very often fixes leave a program that no longer works. It is always easier to revert back to the working code than to fix the new one.

4. Debugging should always be done conservatively. Making too many changes at once makes it difficult to narrow down the source of error. Very often the simplest of algorithms and constructs are sources of undetected errors. Programmers with experience tend to be lax when writing routine code.

5. Finally, what keeps a programmer sailing in crisis is attitude. It is all too easy for a programmer to find faults with the compiler or the computer or the software installation when the code is not working, while it may actually be a small unobtrusive bug.

Well, laws for fine coding have been developed, but how do we ensure that these laws are adhered to? What can we do to keep the "exciting programmer" in check?

There are a number of tools available that assist programmers. The "Code Wizard" developed by "Parasoft" (www.parasoft.com) is a static analysis tool. The tool can be used to ensure that the code conforms to the your coding guidelines. This tool detects almost all deviations from the coding guidelines. A number of tools that perform "automated unit testing" of the code are also available. A number of such tools are listed at www.qalinks.com. "Silk Test" available at www.segue.com is one such tool that can perform unattended testing and has the ability to test across multiple platforms, browsers, and technologies. And then, of course, there are debuggers. Debuggers are programs that help in debugging and are developed for a specific language. A large number of debuggers are available for all popular languages and can be easily searched using a search engine.

Home
Top