From: "Bruce D. Wedding" 

Kurt and Bob,

First off, it isn't a corporate or management strategy.  It was invented by
programmers for programmers.

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.

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

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

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

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

> 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
also do not equate collective responsibility with no responsibility.  The
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.

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

> One thing none of your description addresses is how well the scheme
> supports CMM. Forget ISO-9000, CMM is the only valid metric for companies
> trying to insure software quality.

I don't see why is it the only valid metric?  We produce FDA approved
medical device software and I'm the only one there that even knows what the
CMM is.  The processes defined by CMM at various levels existed before the
CMM existed, it was defined by them, not the other way around.  In any
event, here is an article addressing the very issue if you care to read:
http://www.xprogramming.com/xpmag/xp_and_cmm.htm

> Any scheme which doesn't clearly
> address responsibility and accountability will have problems in a CMM
> enhancement environment. From my perspective, your description has lots of
> room for denied responsibility and finger pointing when things go wrong
> (and, sooner or later, things *will* go wrong!)

Bob, the goal is the creatiion of quality software.  There is only one
output, the software, and if it doesn't work, the TEAM is responsible and
accountable.  In my experience, finger pointers point fingers regardless. 
I remember the last time my boss pointed a finger at me with a CC to the
director and the VP in the email.  I did a reply to all and reminded her
that when you point a finger at someone, you have 3 pointing back at you. 
I pointed out about 7 of her bugs to each of mine and she quit that crap.

But, the real point is.  None of that gets you any closer to quality
software.  If the code is broken, it is irrelevent who broke it.  What is
relevent is the root cause and how do WE fix it?

> It might be OK in a typical desktop environment where everyone is using
> CASE or RAD tools. But when you get to a situation where real programmers
> are writing real programs rather than letting a machine patch together
> boiler plate, you need a responsible architect and a coherent design
> strategy.

Ignoring the obvious slight to application programmers,  I respectfully
disagree.  I've spent the last 5 years working on medical device software
that uses VxWorks RTOS and no CASE or RAD tools and I think some of these
concepts would have been of great benefit.  I will also note that none of
what I posted addressed the design which seems to be what you're taking
issue with, other that the part about prioritizing.  XP does address design
issues but I was focusing more on.  You seem to infer that a large
multi-programmer project starts with 12 guys at 6 computers with 6 blank
source files.  I doubt that is the intent.

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

> Except for the restatements of the obvious ("breathing is good"), I'm
> generally underwhelmed. From what I've seen, most management fads have
> their basis in companies trying to minimize payroll costs without
> sacrificing quality or functionality. That's not necessarily a bad goal,
> but the fact that each year brings new fads tells us that each one has
> flaws. The obvious solution - to recruit the best staff possible, give
> them room to be creative, and retain them by treating them fairly - flies
> in the face of conventional business wisdom today.

I find our differing viewpoints quite interesting.  I didn't see this as a
management fad.  Perhaps I'm naive but I saw it as an attempt to improve
the pitiful software development situation present.  We've all seen the
numbers regarding the number of defects in released software, the
percentage of software projects that are late or never even finished.  I'm
not saying this is the solution to all of that, just an attempt.  I've
never practiced this stuff, just read a book or two.  I think there are
things to learn from it and things to leave behind.

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