Lists Home |
Date Index |
- From: Philippe Lourier <email@example.com>
- To: firstname.lastname@example.org
- Date: Fri, 15 Dec 2000 10:46:41 -0500
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"
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
Audio and video presentations and interviews
by members of the XP community:
Of course a substantial part of the XP movement is about
selling books. --PL
Dr. Dobb's TechNetCast
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..."
>Ekam sat.h, Vipraah bahudhaa vadanti.
>Daamyata. Datta. Dayadhvam.h
>From: Tim Bray [mailto:email@example.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.