comments inline:
On Wednesday, February 23, 2005, at 08:18 PM, David wrote:
2 cents on code reviews:
I find that there is a place(s) for code review in the release cycle
itself. A 3rd party reviewer is not going to be as familiar with
software as an inhouse developer and will be far more expensive.
Between a third-party reviewer and an in-house staffer, there are going
to be some give and takes when it comes to code audits. Just like every
solution out there, ROI analysis for your particular organization is
essential. We know no one particular process is always going to be the
right way.
The part you mentioned I that find interesting is, "familiarity with
the code", which I have question about. Is this a good thing when it
comes to auditing code? Are code audits more effective with a fresh set
of eyes or someone already familiar with the software? It seems to me
that both have benefits, though I'm not certain on what they might be.
From this perspective It doesn't matter if the person is in-house or
out-house.
Why not have inhouse developers check each other's code as part of the
release cycle?
Several open source initiatives use a similar model.
The answer I've heard most often in organizations is that you want
"developers" writing code, not auditing code, because you lose they're
productivity. Auditing code should be done by someone else (Who really
doesn't exist in most cases). Not that I agree with the premise, but
this is what I hear. :)
Before anything gets released another developer should look over the
originator's code. This could also be done by the developer manager as
well. This is sort of like having the fox gaurd the henhouse I admit
but just as security should be multi-layered so should commitment to
quality if you expect to have it. Then, semi-anually, take time to go
back over the code and have bug-hunt month or week or whatever. This
(bug hunt week/month every so oftern) is what we did at my old dev
shop and it mostly worked as a compromise between slamming out
software as fast as humanly possible and having software that works.
Damn those project managers and their rigid schedules!
You found a balanced process that works for your organizations needs
and keeps everyone happy. Did your developers go over they're own code,
or everyone else's code? What were the results like?
This may be unrealistic for most companies as the business side
typically demands on schedule releases without bugs in the first place
and doesn't see as high a value in 'skipping' releases to look for
bugs that 'shouldn't be there in the first place'.
Quality, price, speed. Which 2 do you want? Sales, marketing, and the
board seem to take price and speed every time. Developers will take
quality and speed every time but then they don't control the
checkbook... IT on the other hand will take quality and quality.
"Screw speed and price! We want security and flawlessness!"
I like this. This is a great way to characterize the commonly found
motives within the business.
Regards,
Jeremiah-
