Re: "Selling" a code-audit.

From: Zed A. Shaw (zshaw_at_novantas.com)
Date: 09/22/04

  • Next message: Michael Howard: "RE: Inspecting Code for Security" 
    To: secprog@securityfocus.com
Date: Wed, 22 Sep 2004 16:04:46 -0400

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

  • Next message: Michael Howard: "RE: Inspecting Code for Security"
    • Quantcast