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 > > > >