Hi,
First time posting here. I thought I would give a real experience I had
related to the below two comments.
In one job I was asked frequently to review people's code for "potential
security flaws". This organization (who shall remain nameless) was
notorious for exactly what Jason wrote: They would demand that software
be written at break-neck speed and at any cost, and then when their
demands weren't met they would start firing people. Typically this just
meant firing people they didn't like for no reason. It was actually the
perfect management smoke screen for their inability to properly plan a
project.
Eventually though, developers got wise to the situation and started
doing things to make management accountable. It wasn't a united front
by any means, but they would build evidence, keep logs, write memos,
anything to make sure that if a manager tried to fire a developer for a
particular decision, then the developer could point at something and
say, "But you made me do it!"
It was about this time that management figured out they could take
advantage of my code reviews. Most of the time my reviews weren't
public or formal. I would just find some bugs in someone else's code
that was causing me problems and I'd go talk to the developer. A lot of
times I'd just fix it myself. It was originally what they hired me for,
but I found you can't polish a turd so informal was the best I could do.
Then management started asking me for more formal reviews. They'd point
me at CVS and say, "Review that dude's code. Tell us what you think."
I'd oblige and give an honest fact based opinion, but I was suspicious.
At first I thought it was to see if the design decisions the managers
forced on the developers were the right ones. Man was I naive. I found
out that management was using my reviews as the new basis for firing
people. It took about four people getting axed before I got wise and
stopped doing it, at which point they started threatening me with
termination unless I did it and I eventually quit under the pressure.
Now, here's an example before you think, "How much control could
management possibly have over the implementation?" In one instance they
decided to implement what was effectively a web based Kerberos (don't
ask why, you'll just go insane). Not only did management dictate that
this be done in 6 months (that was the magic number for all projects),
and that it be integrated into everything else in 6 months, but one
manager event went so far as to completely design the protocol, the
encryption standards, the formatting layers, everything short of the
actual code. He even dictated tools to use and deployment scenarios.
Yet, in the end he fired the guy who wrote it for these exact choices
and justified it with one of my code reviews.
These days I'm pretty much against code reviews unless it is part of the
daily development process and management is not involved (i.e. it's kept
as a dirty secret among friends). I do think they have merit, and I'm a
firm believer in "exposing incompetence", but I don't think people
should be fired over this. In almost every case I've experienced before
and after this incident I can say that management is control of 80% of
everything developers do. This is also supported by quite a bit of
management research in recent years. If that's the case, then code
reviews really show how management's decisions are affecting code
quality more than they show the quality of the developers.
Anyway, that's my experience on the subject. Just a war story for
people who might consider this. If you do it, please try to set it up
so that it's not used as a weapon to "clean house". I don't think
anyone here is advocating that, but that's usually how I've seen
management approach it (well, bad management anyway).
Have a great day!
Zed A. Shaw
On Tue, 2004-09-21 at 06:20, Jerry Connolly wrote:
Jason Coombs PivX Solutions said the following on Mon, Sep 20, 2004 at
07:39:54AM -1000,
[..]
It does appear ironic and absurd for management to then punish the
developers for meeting the schedule by having a code audit pick apart all
the things the developers were forced to skip over in order to finish on
time.
Where are you getting this assumption from the original mail? I read and
reread and found no evidence of it. Apart from the fact that developers make
lots of security mistakes without realising, it is not a given that speed over
quality will be prioritised (rightly or wrongly from a competitive point of
view).
