From: Jonathan Guthrie 

On Wed, Apr 28, 2004 at 08:47:11PM -0500, Bruce D. Wedding wrote:
> 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?

>From the management perspective, blame is important because avoiding it
is useful in building the little fiefdoms that some managers seem wont to
build.  If it is important to the people that call the shots, then, by
definition, it is important to the people whose shots are called.

>From the programmer's perspective, the assessment of blame is important
because it helps you determine what not to do the next time.  That sort of
feedback is essential to the CMM as it helps improve the process.  If you
don't know how it got broke you can't determine how not to break it next
time.

>From the management's perspective, then, avoiding blame, one of the
purposes of doing the "everybody owns the code" is the right thing.
>From the programmer's perspective, it's a disaster because you can't
learn from your mistakes unless they get pointed out and criticized.

One of the things about "Extreme Programming" that I find, um,
well, ludicrous, is it's supposed to be "of the programmers, by the
programmers, and for the programmers" but it's full of stuff like this
that is not in the best interest of the programmers.  Assigning blame is an
important part of improving the process and it is up to the lead
programmers to show the followers how to give and accept blame so that it's
not an accusation, but an opportunity to become a better programmer.

Incidentally, the way the members of a team handle criticism is an
indicator of the health of the team.  If people can point out errors and
it's no big deal, then you've got a healthy team.

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

Are you aware that there are no conformance test for ANY protocol defined
by an IETF RFC?  You might ponder why there are no tests for the best
defined specifications in widespread use.  If you've never written such a
thing, I have.  Getting complete coverage is quite difficult even for the
simpler protocols.  In other words, both your "specification is
complete" and "written the tests properly" are things rarely
seen in practice.  (In a meeting yesterday, I got to give the spec for the
software I was hired to write and it boiled down to "Make it standard,
make it work with common clients.  Make it without extensions.  Write it as
fast as possible."  One thing you might notice is that the spec is
self-contradictory, but it's wordier than many of the specs I've gotten.)

> 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?

I complete roughly 75% of my major software projects on time.  Here's how
to do it:  Start with a clear idea of what is to be delivered. Next, add a
sane schedule.  (An old engineer can tell you how to create a sane
schedule.  What I do is break up the project into small steps, multiply the
number of small steps by 2 weeks and then add 25% or so for padding.) 
Design to handle more complexity, usually a LOT more complexity, than the
project appears to need at first glance.  Implement the essential
functionality first.  Add nonessential functionality in order of decreasing
priority.

The implementation of the essential functionality is the crucial step. It's
vital that the program be useful for something as quickly as possible. 
Then, one can add features a few at a time and the rate of enhancement goes
quite quickly.  Things that aren't essential are things like reading
configuration files.

Most of the skill lies in designing an architecture that is elaborate
enough to handle more complexity than you anticipate without bogging the
first part down with stuff that won't be relevant until the end of the
project.  Most of the rest lies in deciding what the "essential
functionality" is.

Also, this is a recipe for delivering a program on time.  Heed Brooks'
advice that turning a program into a product is likely to take an equal
amount of time as creating the program takes.
--
Jonathan Guthrie (jguthrie{at}brokersys.com) Sto pro veritate

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