From: "Bruce D. Wedding" 

I'm glad I chose a topic that injected some life into this place :)  I'm
just commenting on a few remarks that I found interesting.

> I do - much easier to deflect blame in large groups than with single
> points of responsibility.

Is this a disease in our industry?  You're the second one here interested
in blame and I have encountered it in my work also.  Of what relevance is
it, who broke the code?  What is relevent is, how do we fix the code.  Get
out of the pointing finger game, it is a non value-added activity.

> That last "If" is a very, very big "if".  If you
don't know the code,
> you'll just (subconciously) rig the tests to pass.  Doesn't always
> prove anything.

I strongly disagree.  If you've written the tests properly, meaning the
tests verify the functionality of the specification, and the specification
is complete, then it is not  a big if at all.

> We integrate and build many times a day.  Doesn't help quality as much
> as we hoped - we have many other quality initiatives to try to help.

You can't take one piece of the program and fault it for not working Darin
when they are all interdependent.

> BTDT?

Been there, done that.

> I would have to say that what a programmer can handle is nearly
> completely independant of their experience.  The idea we have is to
> identify our stars, and give them the critical paths.  I think that's
> how I managed to find myself without significant coding responsibility.
>  ;-)

LOL!  Many projects have been written by stars eating flat foods, I agree.
OTOH, Dynamics of Software Development warn about this very thing,
referring to it as "Beware of AGuy in a Room."

I'd also like to make clear that I'm not a proponent of XP.  I've only
began looking at it.  I AM a proponent of doing something different.  I've
never been on a software project of significant size that shipped on time
and I've been doing it for 15 years now.  There has to be a better way. 
Let's figure it out and get rich, ok?

--- BBBS/LiI v4.01 Flag-5