Common mistakes of Software developers

Introduction:
Most Software developers are not even aware that there favorites methods are problematic. Quite often experts are self thought, hence they tend to have the same bad habit as when they first began, usually because they never witnessed the better ways of performing their embedded systems. These experts then train novices who subsequently acquire the same bad habits. The purpose of this presentation is to improve the awareness to common problems, and to provide a start towards eliminating mistakes and thus creating software that is more reliable and easier to maintain.

It is easy for spending a million on testing a program. Common estimation of the cost of finding and fixing the errors in program range from 40% to 80% of total development cost. Companies don’t spend this kind of money to “verify that a program works”. They spend it because the program doesn’t work, it has bugs and they want them found. No matter what development methodology they follow, their programs still end up with bugs. Beizer’s (1990) review estimation the average number of errors in program released to testing at 1 to 3 bugs per 100 executable statements. There are big differences between programmers, but no one’s work is error-free.

One error per 100 statements is an estimate of public bugs; the ones still left in program after the programmer declares it error-free Beizer (1984) reported his private bug rate, how many mistakes he made in designing and coding a program, as 1.5 errors per executable statement. This includes all mistakes including typing errors.


“At this rate, if your programming language allows one executable statements per lines, you make 150 errors while writing a 100 lines program.”

Most programmers catch and fix more than 99% of their mistake before releasing a program for testing. Having found so many, no wonder they think they most found a lot. But they haven’t .Tester’s job is to find the remaining 1%.

Correcting just one of the mistakes within a project can lead to week or months of savings in manpower (especially during the maintenance place of a software life cycle.).

Some of the common problems are :

Large if-then-else and case statements:
It is not uncommon to see large if-else statements or case statements in embedded code. These are problematic from three perspectives.

1.) They are extremely difficult to test, because code ends up having so many different paths. If statements are nested it becomes even more complicated.

2.). The difference between best-case and worst-case execution time becomes
significant. This leads either to under-utilizing the CPU, or possibilities of timing errors when the longest path is taken.

3.) The difficulty of structure code coverage testing grows exponentially with the number of branches, thus branches should be minimized.

This example confuses new testers who lack in programming experience.
Developers think their code is always correct and as mentioned earlier 99 % errors are corrected by themselves and remaining 1%.errors will be found out by testers. In the below example the
IF (0 < x < 12) then
SYSTEM.OUT.PRINTLN (“Month is” & i);
Else
SYSTEM.OUT.PRINTLN (“Invalid input”);

Consider how this code could fail. Here are some of the simple programming errors that are very common mistakes that can go wrong:
a) Suppose the programmers said less than or equals instead of less than. The program would eject 0 as bad character. The only way to catch the error I by testing with 0.

b) If the code is written as less than 12 instead of less than or equal to 12, the program would go wrong.

“Testers with just the four boundary characters, /, 0, 9, and: will reveal every classification
Error that the programmer could make by getting an inequality wrong or by mistyping”

Error Handling:

Errors in dealing with errors are common. Error handling errors include failure to anticipate the possibility of errors and protect against them, failure to notice error conditions, and failure to deal with a detected error in a reasonable way. Many programmers correctly detect errors but then branch into untested error recovery routines. These routines’ bugs can cause more damage than the original problem.

Some times the errors are more even large while executing the tests and the Microsoft’s worst scenario is we can’t copy the error messages. There are some tools for copying the text of such error messages and also we can take the screen shots