Re: p5ee xp?

[email protected] (Aaron Johnson) 19 Jun 2002 23:50:08 -0400
Newsgroups perl.p5ee
Message-ID <[email protected]>
On Wed, 2002-06-19 at 22:23, Rob Nagler wrote:
> Stephen Adkins writes:
> >    "What you are trying to do won't work."
> 
> Negative results are always interesting.  XP can work for p5ee, but
> not in the way you expressed it.  If you have customers which are
> using Blue, then you can do XP.  However, you won't be able to take
> input from the people on this list.  In XP (and I think any successful
> software project), the customer must speak in one voice.  It is not
> the programmer's job to sift through the opinions, possibly
> conflicting, of what a programmer should do.
> 
> This is why bOP is not bazaar.  For example, we recently added
> e-commerce to bOP.  We had been using it for bivio.com, but there was
> no reason to split out the e-commerce infrastructure.  One of our new
> projects needed e-commerce, so we refactored the e-commerce piece of
> bivio.com and released it with bOP.  The change required a major
> database upgrade and potentially introduced a number of bugs into
> bivio.com.  We refactored the code only when it had business value to
> do so.  The refactoring allowed us to share the code between multiple
> projects and give it away as open source while earning bivio Software
> Artisans money and giving our clients reliability through reuse.
> 
> You can make P5EE work.  Here are the steps:
> 
>     1. Get a single customer who drives the project.
>     2. Solve her problem.
>     3. Release the common infrastructure as open source
>     4. Repeat

I don't agree.  XP in your context will not work for P5EE.

P5EE is an abstraction of processes required to produce Enterprise grade
products/services (or at least I thought thats what it was).

If you take the piece meal approach you will be constantly reworking the
architecture.  The entire process needs to be broken down into the core
areas of importance for enterprise systems.  I believe this was
discussed in the previously on this list.

By isolating what is redundant between products/services the base
architecture can be the building blocks for the portions that are unique
to a particular company.

My idea of P5EE is to produce the following:

- A list of verified modules that meet a coding standard and have proven
durable enough to be considered enterprise worthy/capable.

- A polished and easy manner in which key modules not provided in the
core can be added to a virgin system. CPAN is great, but it isn't as
simple/slick as what the competition is pushing.  The web based CPAN
interface that ActiveState came up with is a step in the right
direction, but it still doesn't make it simple enough.

- Consistent documentation on how these components work, that is the
documentation is written in a single voice and demonstrates how the
modules work in concert.

- Regression testing and testing standards for modules.  Or at the bare
minimum people that are willing to test new releases in there
environment and report back any issues/concerns.

From that the project can grow to provide a unified interface/naming
convention to the above the core modules. In other words from consistent
one voice docs to one voice method names that make it easier for a
developer to know what he is doing/working with.

Aaron Johnson

> 
> Rob
> 
> 
> 
>