Re: Re: Firewalls breaking stuff: [Was re: fwtk]

[Paul Robertson <proberts () patriot net>]

On Tue, 23 Jul 2002, Dana Nowell wrote:

> In my experience, it depends :-).  In general if the code removed was all
> the simple boilerplate stuff and the code remaining was all the nasty
> complex stuff, the absolute number of bugs remains roughly constant and the
> number/kloc increases.  It's the age old issue, bugs/kloc implies that all

Right, there's a complexity modifier, however it averages out if the 
project is large enough (think of it as bug cost averaging.)  However, on 
suitably large projects, there's a somewhat offsetting "bordom" related 
thing- and with some development teams, the emphasis gets put on debugging 
and verifying the "hard parts" rather than all of the code.

> kloc are created equal, and they aren't.  In fact they are frequently not
> even close.  Take a good programmer, have him/her write code they are used
> to writing, take same programmer have them write nasty low level protocol
> crap they have never even heard of before, wanna bet the bugs/kloc are the
> same?  Now assume you have someone working on a project where 70% is simple
> straight forward stuff and 30% is mean nasty low level crap they've
> never/rarely done before.  Because I'm a security minded manager, I remove
> one third of the project, but from the simple part, I keep all the nasty
> stuff because I need it.  Are you REALLY saying I dropped one third of the
> bugs?  REALLY?  

Obviously it's not linear, but I'll make a bet that you drop a 
proportionally representative ammount of bugs weighted by {complexity, 
time, attention span...}

> Now if you were implying the age old, "the programmer used is equally good
> at all aspects of the project" hence all kloc are the same...  Can I hire
> YOUR staff, mine seems deficient. :-).

It's been my experience that bugs/kloc has been fairly constant per 
developer where I've done product development.  Maybe my sampling isn't 
large enough to make that a generic rule, but it's my experience.

But then maybe that's becuase when I paid enough attention to track it, it 
was because the ratio was too high (ammunition for keeping other people 
out of my part of the codebase due to time spent repairing their "fixes")- 
that is "the programmer used is equally good at all aspects of the 
project," where "good" == "sucky."

I extrapolated forward because I think Wietse's stats for Postfix have 
held fairly true (and he's not "sucky.")  Also, some of it is 
based on experience of what I've ripped out of systems prior to 
deployment and the subsequent patches and upgrades I haven't had to deploy 
because that code wasn't in what I sent out.

Paul
-----------------------------------------------------------------------------
Paul D. Robertson      "My statements in this message are personal opinions
proberts () patriot net      which may have no basis whatsoever in fact."


_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards