Code Review Necessity Software Engineering Help

Code Review Necessity

Simply put, a code review is carefully glancing through the source code of a program already written by somebody else. Generally, one reads through his or her own program several times at the time of writing and particularly once it is done. Is it then still necessary that another person look into one’s program? The answer is undoubtedly YES and is explained in the next few lines.
It is human nature to have a sort of affinity to our own creation – like a picture painted, and article written, etc. due to the passionate creativity that goes into it. A software program is no exception. It is precisely for this reason that one tends to fail to spot any mistakes in such a creative work and is incline to reassure oneself over and over again that all is well in that piece of creation. This is due to our natural tendency at a very subtle level to ignore our own mistakes. Legendary scientist Issac Newton is said to be have carved out two holes in his room door for the smooth traffic of his pets – a moderate hole for his cat and a small one for her kitten.

Coming to the software development, way back in 1971, Gerald Weinberg a noted computer scientist expounded a fascinating concept of Egoless Programming in his article entitled ‘Psychology of Programming’. He explained how almost everyone is prone to commit some errors in programming that could not be figured out by same programmer.

Reason is that one who has written that program would intuitively and unintentionally follow the same logical thinking that he or she has trodden on while actually writing that program. In other words, when checking the program against some yardstick, that yardstick and program would perfectly match in almost all the cases giving a false notion that the program is flawless. Weinberg then went ahead one more step and appealed to the programmers that the act of programming should be egoless; meaning that once the program is completed, the programmer should not attach his self worth to that program, rather freely allow another programmer to spot errors so that they could be rectified.

Research has shown over a large number of years that a code review is an effective tool for quality assurance, bringing about 15% to 40% improvisation by removing extraneous code, boosting efficiency, sorting out ineffective logic, spotting deviations from corporate programming standards, etc. as could be noted from the following examples:

1. On the time and cost line, Roger Pressman has vividly shown in his book on software engineering that the cost of rectification increases manifold as the project proceeds ahead. He narrates that the cost of rectification of an error is say 1 unit, if spotted the design phase. The same error may cost 6.5 units if figured out in reviews, or 15 units if located in testing, and worse still, 60 units if the error creeps in the version rolled out to the users.

2. In another illustration, Edward Yourdon tells us that when he and his 3 other colleagues reviewed the 200 lines of a program in about 45 minutes, as many as 25 bugs surfaced, out of which at least 5 were such that they would have never been traced in testing.

Expertsmind.com, computer science & computer engineering assignments, software engineering home works, online tutoring and projects help.

Reference: Blog.co.uk