From: Darin McBride 

[Side note - these messages are getting to fido, but I'm not seeing
anything from fido getting back to the list as of recently...]

On April 27, 2004 8:09 pm, Bruce D. Wedding wrote:
> Kurt and Bob,
>
> First off, it isn't a corporate or management strategy.  It was invented by
> programmers for programmers.

This I believe.  I actually expect that Bob was on to something when he
mentioned open source programming - this may actually have evolved from the
open source bazaar programming model.

> KK> It all seems pretty solid, though I prefer to putter about on my own.
>
> Me too.  My own preference is to take the good ideas from this and leave
> what I think are the bad ideas.

Fair enough - although what is "good" and what is "bad"
is somewhat subjective.  ;->

> > > 1.  Planning - Prioritize the next release by combining business
> > > priorities with technical estimates.  Basically, perform the
changes in
> > > priority order.
> >
> > This restates the obvious.
>
> Bob, I doubt you would be surprised if I told you that I seldom see this
> happen in the real world.  Come to think of it, I've NEVER seen it happen
> in the real world.  We develop a specification and begin coding and at that
> point, everything is at the same priority.  Its in the spec so it MUST be
> completed.

I see this in two places in my current position:

1. Design phase.  We put in large numbers of items of work, then we remove
lower-priority items from the queue until the estimated amount of work is
equal to the amount of resource we have available.

2. End-of-cycle.  We yank out nice-to-haves from the queue until we can
state that we can ship.

In the middle, your experience matches mine.  Personally, I try to keep my
own team on priority track the entire way through the release cycle.
 That is not always easy - for example, we have one minor, nice-to-have
project that was done first because we're hoping that it saves us enough
development time over the release to pay for itself before we ship.  Not
critical, but we made it a priority.

> > > 3.  Testing - Continuous unit testing.  Tests are written as code is
> > > written.  Customers write and run feature tests.  An integration test
> > > must be run at each build.
> >
> > Again, this *should* be restating the obvious, but frequently it's not
> > done.
>
> And I've never seen it done to the extent that Extreme programming
> suggests. When writing in C++, every class has test methods that test the
> class functionality and must be updated anytime a method is added to the
> class. All class tests are invoked by one call to a base test class.
> Examples are: http://www.xprogramming.com/testfram.htm

Yes - all too often, testing is shunted to end-of-cycle and thus first
thing cut when cycle runs long.

> > > 4.  Refactoring - Continuous refactoring.  Simplify, remove
> > > duplication, add flexibility.
> >
> > Improving algorithms is the most reliable way to enhance software
> > quality. However, if there's more than one programmer working on it,
> > coordination and communication become major issues.
>
> "Improving algorithms" is a broad statement so I'm not
exactly sure what
> you mean.  Refactoring encompasses much more than what I think of when I
> say improve algorithms.  There are over 70 refactorings listed in
> "Refactoring: Improving the Design of Existing Code."  They fall into
> several broad catego ries ie: simplifying code, reducing duplication,
> consolidating methods or as simple as renaming a method or function.
>
> As for coordination and communication, they are major issues either way,
> no?

Most of the projects I do now are single-person projects.  Kinda sad, I
suppose ;-)  I take a small, small piece of the overall puzzle, sit in my
own little corner for anywhere from 2 days to 2 weeks, and pound out a
solution, then integrate.  But when I need to involve someone else, it
usually takes 2 days just to explain to them what is going on.

> > > 5.  Pair Programming
> >
> > Bull sh*t!!! I won't/can't work productively either with someone looking
> > over my shoulder or holding someone else's hand. I've actually quit jobs
> > rather than be stuck with this sort of arrangement.
>
> LOL!  I don't like it either Bob.  Whether I'm in charge or not, it is no
> fun and difficult to remain focuses if you don't have the keyboard.  I
> actually get headaches from trying to follow code while some bozo is paging
> up and down.  I hate it.

It doesn't work well for me, either.  A significant portion of that is
because I work at home ;->  Another significant portion is that all my
coworkers are 3200km away from here.  ;-)

We actually went the other way - each developer has two machines in their
office.  And us unix weenies also have access to 65+ other machines of
about a dozen different multi-user unix platforms.  No sharing whatsoever!

> > Collective ownership = collective responsibility = no responsibility or
> > accountability. This could only work if everyone had the same level of
> > knowledge and experience. Otherwise, you will have well-meaning but
> > clueless tyros "improving" critical code.
>
> They will tell you that this will be caught by the pair programming.  I

Only if one of the pair knows what's going on.

> also do not equate collective responsibility with no responsibility.  The

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

> code has to pass the unit and integration tests before being accepted into
> the master source.  If it doesn't, you know that you broke it and have to
> fix it, hence learning the code.  If you have something
"critical" then
> certainly your tests will ensure that it operates as it should, meeting
> schedules, calculating properly, etc.  If the tests are properly written,
> then broken code can't be integrated.

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.

> > > 7.  Continuous Integrations- integrate and build many times a day.
> >
> > I'm sure this creates the illusion of productivity among those who can't
> > tell the difference between movement and progress.
>
> I think you miss the purpose.  The purpose is that you build after each and
> every change so that it is patenly obvious through integration testing,
> what is broken and what works.  The benefits are seen in decreased
> debugging time.

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.

> > I've been there. The whole "pair programming" thing sounds like a
> > corporate strategy to hire lots entry level programmers and force them to
> > interact, hoping they'll make up in epiphanies what they lack in
>
> experience
>
> > and depth of knowledge.
>
> Recalling that I'm generally opposed to pair programming, I believe the
> intent is to disseminate information from the experienced to the less so as
> well as spread the knowledge.  The obvious problem with your solution of
> having the guru do all the "critical" code is that the guru
leaves one day
> and you're up a creek.  BTDT and had to pick up the pieces after he left.

BTDT?

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

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