Lists Home |
Date Index |
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Philippe Lourier <firstname.lastname@example.org>, email@example.com
- Date: Fri, 15 Dec 2000 10:00:07 -0600
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.
Intergraph Public Safety
Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h
From: Philippe Lourier [mailto:firstname.lastname@example.org]
Sent: Friday, December 15, 2000 9:47 AM
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"
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.