Re: PL/SQL Code Reviews

Billy wrote:
> 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?

You mentioned performance issues. If the routine isn't returning the data for 5seconds when this is for a web page that needs to display in under 2seconds Isn't the manager going to question that? Then when the dinosaur coder says he cannot make it faster, but you then propose that you can, and then you really do it. Who is the manager going to believe next time?

But like I said, your problem is NOT with the review process.
>
> Remember that managers are suppose to manage time, people and money -
> no technical skills needed.

maybe not coding skills, but communication skills are required. Being able to identify that the technology has changed and the old programming solutions are not cutting is falls in that category. But again, we are outside the review.
>
> > 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.

But which side of the wall are you on that you are in developer reviews and in operations meetings.
>
> > 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. :-)

which shouild have been identified in a code review.
>
> > 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.

And sometimes you need to give the developer room to fail. When the data disappears and the VP is chewing him out, he'll get the message.

But you are right, it works best when all are willing to follow the idea. I've been trying to get code reviews where I am right now but for severl reasons, it's not flying. Thing is I know that I develop better code when there is a review process. Here it's the old code & test.

>
> 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.

I understand, I really do.
>
> 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

Some of those people have really thick skulls and short memories. The real trouble is not that they bump their heads, but they confuse the absense of pain (after the mess is cleaned up) with real pleasure (avoiding the mess to begin with).

Nice talking with you. You made some good points about development teams. That's a whole 'nother topic from reviews. If you want some good reading about it, look up some of the books by Demarco & Lister. And of course the Dilbert Principle.

good luck.
  ed Received on Tue Sep 20 2005 - 07:49:09 CDT