Greetings fellow Monks

This is a dillema about codereview.

I work a at company that creates applications for transport. Basically we make the software that controls the flow of the traffic. It is not one application but a whole bunch of applications that all communicate with each other.

These applications grew and evolved over many years and are written in many languages (C, C++, Java, Pascal, Perl). So we have lots of source code. A few milion lines of code. Some parts are of good quality and comply to our coding standard, other parts suffer from software rot or from too tight deadlines.

A lot of the code is constantly modified as the requirements keep on changing. In an effort to improve the quality of the development process we are thinking of having code reviews. The idea is to review every change to code. It would have been better if all code was reviewed and then fixed, but there is no money for this (nor are there any unittest to make sure nothing breaks when things get fixed).

So management is not entirely happy with code review idea. They worry about what the returns will be for the time invested. They also claim that the reviewers will be overwhelmed by all the faults in the old code each time they have to review changed code.

I proposed to have the reviewer add all remarks in header of a sourcefile so the next time it is reviewed these points can be skipped. Also with a little perl program all the points can be extracted from the code and one can create a nice summary of what needs to be done. But that was rejected since the client then sees how good or bad our code really is.

Does anyone has any experience with this? How can one best review changes to heaps of old code?