Jay,

Re: It seems that XP reflects a bottoms-up rather than top down approach to programming.

Perhaps. Maybe a better way to put it (at least as I understand it), is that Extreme Programming acknowledges the reality that its impossible to write a perfect spec or a spec that stays frozen during the entire development cycle. Instead it focuses on producing a small code base *focused* on very specific needs (none of this 'we need to do this because we MIGHT do that') with a rapid set of small deliverables/turnovers. The small turnovers demonstrate specific needs/features so that the stakeholders can adjust the spec to reflect current requirements (which are always in flux). And the rapid turnover schedule keeps a project on pace.

Re: Even more significant, it seems to me that it tries to formalize how most folks actually do program, "methodology (what an unnecessary word when "method" would be quite sufficient)" or not.

I'm not sure I would agree with the comment 'how most folks program'. Perhaps, you meant to say 'how most folks should program' :) I guess you'll have to read the books to find out!

Re: It relies on intuitive rather than explicit knowledge. And, it trusts the operator!

Yes! Extreme Programming requires a lot of trust. But equally important, its fast cycling of turnovers provides a means to objectively judge where one's trust is warranted. So its trust with a safety net? (I'm searching for a better analogy, but my brain is fading rapidly)

Re: Well, I guess I'll just have to dig in and get some info!

Dig in and lets discuss!

Regards,
Malcolm