Re: PL/SQL Code Reviews

Ed Prochak wrote:

> That's exactly the point. It is their code. If it fails to meet
> functionality or performance specs, then your manager can put on the
> pressure. You as a reviewer cannot and should not pressure the
> developer.

And when they spin technical yarns and the manager does not have the savvy to understand what is fact and what is not?

Remember that managers are suppose to manage time, people and money - no technical skills needed.

> Why isn't the coder in that meeting instead of you? This is where the
> owner of the code has to start explaining why he failed to follow
> suggestions from the review. You already did the CYA move in the
> review, pointing out the potential problems (Your team does retain
> review minutes, right?).

Souds good. But there are often Chinese Walls between operations and development.

> Please don't take offense, Billy, but you seem to take the problems
> personally, even when it is not your code.

Only in production when data "disappears" and the developers firstly blames Oracle for it.. only later to discovered that is is a -very- bad idea to supress exceptions in a trigger. :-)

> Keep the horse proverb in
> mind a little more often. It becomes almost a political process, a
> matter of persuassion, to bring your temmates around. Again I say your
> problem is not with reviews, but with the team. I hope it gets better.

Actually Ed, I'm playing more devil's advocate than anything else (though the issues I raised I have run into personally though the years). Code reviews only work in my experience when all parties buy into it - but developers seldom do as it becomes an ego thing (especially when the review is in his peer group) where you need to prove to the developer why ABC is better than his XYZ.

At the current place I'm contracting, we do not have code reviews at all. Pretty difficult to implement something like this.. I'm dealing with full time developers, external contractors, and senior technical/specialist staff that are forced to write code (prototypes that invariable winds up in production due to marketing windows of oppertunities). They not only report to different managers, but work for different divisions. Thus enforcing any type of coding standards, is mission impossible.

But the proper way to do things are slowly filtering through. How many times do one have to bump one's head before seeing the light? :-)

--
Billy