xml-dev - RE: Extreme Programming goes mainstream?

[Philippe Lourier <pl@technetcast.com>]

One of the basic characteristics of XP is that it advocates
an adaptive approach to engineering software
rather than a predictive one.   It recognizes that
up-front analysis is often speculative.  Requirements
change.  And so it has a built-in "error correction"
mechanism.

But what is interesting is that this
unpredictability extends to software that has already
been released.  In a truly adaptive model you should be
able to selectively upgrade parts of a system after it is
in production.  This is where traditional languages like C++
break.  There is no class evolution in C++.  To evolve a
class in C++ you need to recompile/link an entire system.
This is one problem component object systems were
trying to solve.

The iterative approach taken to the limit requires a
a dynamic, networked environment and tools and
protocols that support software evolvability.  And
this is where I'd see the link between XML and XP.
Application protocols like SOAP or XML-Protocol or
whatever it turns out to be promise to create this
type of environment.

Btw, Martin Fowler categorizes XP as a "lightweight
methodology", a category that also includes open
source development:
http://www.martinfowler.com/articles/newMethodology.html

Audio and video presentations and interviews
by members of the XP community:

http://www.technetcast.com/tnc_catalog.html?item_id=746

Of course a substantial part of the XP movement is about
selling books.  --PL

---
Philippe Lourier
Dr. Dobb's TechNetCast
http://www.technetcast.com
---







At 08:24 AM 12/15/2000 -0600, Bullard, Claude L (Len) wrote:
>Pair-based programming is probably better than
>the notion that having lots of eyes look at code
>improves it and everyone seems to accept that one.
>That they should both be on the same machine seems
>both awkward and unnecessary.  The problem here
>is picking the right pair and making sure that
>they have and will use complementary skills.  The
>problems of the "insular coder, the lone hacker,
>the hero programmer" etc are well known and have
>caused many a business model driven project to
>fail.  The other extreme of that are the
>secrecy obsessed organizations that breed
>personal competition into every level of their
>employees with carrot and stick management.
>
>This makes XP almost impossible to implement
>in the development groups and leads to the
>very common inter department schisms between
>the business types (the suits) and the
>artistics (the programmers).  We are watching
>some well-established firms dropped to their
>knees in their stock prices as the market
>observing a lack of innovation and the failure
>to deliver on promises made lose confidence
>and simply ignore these companies.  This is not
>just a dot.com problem; it is epidemic in the
>computer science industries particularly where
>the CEOs and CTOs have yet to understand that
>the Internet business is not about building
>a barrier of complexity to competitors; it is
>about building simple strong bridges to allies.
>
>You have to pick a model for interaction that
>scales up the levels of the organization.  You
>can't depend on a power elite; you must depend
>on a process that self-validates and self-organizes.
>In a sense, these organizations work much the
>same way an XSLT stylesheet works; it tries
>as much as possible to remove a dependency on
>globals and relies on smart recognition of
>patterns.  That is why the pairing must be
>precise; what each one recognizes as they
>work together is vital.  It isn't a pissing
>contest; it is a game of styling.
>
>The problem is control, how to get it,
>keep it, and use it wisely to ensure your
>company is profitable and employees
>are satisfied.   Unless you can do this,
>the business plans will not be met and
>no amount of cajoling or browbeating will
>change that downward slide.  Our business
>depends both on application and innovation
>and knowing when to do which of these for
>some given project.  Whatever else you do,
>you must train fear out of the employees
>and yourself.  Knowledge and a certainty that
>what is learned will be applied sensibly leads
>to confidence.  XP, done well, leads to confidence
>in the code and the product, thus the management
>must be the styler of confidence, it cannot
>be simply, confidential.
>
>"The problem is not in the stars..."
>
>Len
>http://www.mp3.com/LenBullard
>
>Ekam sat.h, Vipraah bahudhaa vadanti.
>Daamyata. Datta. Dayadhvam.h
>
>
>-----Original Message-----
>From: Tim Bray [mailto:tbray@textuality.com]
>
>Maybe, 20 years after I got into this profession, we can
>finally leave behind the notion that the business people
>will write a complete spec for what they need, and the
>programmers go implement that.  It's never worked outside
>of a few specialized domains, and never will.