xml-dev - RE: Extreme Programming goes mainstream?

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Which sounds good on paper but is a stone cold 
nasty problem in a contract driven system of 
testable deliverables over services.  The adaptive 
approach works well at Burger King where all the 
positions are interchangeable and the components 
are tested, tasty, and available.  Software engineering 
when coupled to product delivery is not easy to 
do as a service model.

The problem is when the system is complex, highly 
customized, and costs are recovered in accordance 
with a delivery/test acceptance schedule.  Enabling 
constant adaptation means you must have very precise 
contract models for who gets to request and adaptation. 
Failing to recognize gold-plating, rice bowl requirements, 
extensions based on lack of up-front analysis, and 
so on can quickly put you out of business.

Its about recognition of patterns and picking the 
right template.  Adaptation is a pattern recognition 
problem with feedback-based controls.   
Can you create a root pattern that works 
just as well for the business model as it does 
for the engineering problem?   The success of SOAP, 
UDDI, etc. will rise or fall on the means by which 
discovery and recognition of a service can be 
followed by negotiation for terms and conditions 
that satisfy a requirement.  Otherwise, you just 
don't get paid.

The recent American election is revelatory of the 
issues of small noisy systems that contribute to a 
binary decision which results in a tie.  Don't look 
at the politics; look at the pattern recognition 
and how lack of robust standard templates makes 
for a messy outcome.

Len Bullard
Intergraph Public Safety
clbullar@ingr.com
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Philippe Lourier [mailto:pl@technetcast.com]
Sent: Friday, December 15, 2000 9:47 AM
To: xml-dev@lists.xml.org
Subject: RE: Extreme Programming goes mainstream?



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.