Bernard, I agree a lot with what you say. I wonder if it wouldn't make sense to have a 2-cycle XP process, where there is an architecture and a code component of each iteration. For the very first one, a general architecture is worked out with whatever level of specificity is appropriate and allows people to begin work. In a simple system, this might be nothing. In a distributed system, this could be significant and involve specing protocols, etc. After the first design cut, coding begins on iteration #1. Every iteration after that begins with a new design cycle, which is really just addressing whether the design from iteration N-1 still seems appropriate and is doing what it needs to. If it needs to change, it does now. When this is close, move on to the coding for that iteration. It's not a huge difference, and maybe defacto it happens like this anyway, but this approach goes a long way to addressing my concerns with the XP lack of design without sacrificing the agility. An inordinate amount of effort is not spent up front, just enough to make sure that every bit of work in this iteration won't be refactored out of existence next iteration. This is where patterns could come into play, not with each developer hacking away to solve their individual problems but in the pre-coding design phase (that all developers would participate in) and at which common problems could be abstracted and patterned.


For the building ahead, here's an example from my current self-directed project (the one about which I started this thread). I'm learing Struts for it, and also Hibernate. I have a data schema that I have arrived at over years of thinking and sketching and I finally felt like pursuing this project. The XP way says that when I was making my JDO style objects to hold the data, I don't build the ones that I don't need now. Maybe it turns out later that I don't need them at all. What I did was to build every data object I thought I would need later on. They were all unit tested and since they interact, by the time I got to the later, more highly derived ones the fundamental ones had been well tested. Before I ever touched the web end with Struts, I had my data objects down solid.

When it came time to start with Struts, like any Struts beginner I was highly frustrated. One of the saving graces of gutting out that part of it was that all my JDO had already been built, all worked and I could take it as a given that they were there and performed correctly. I got an economy of scale for doing them all at once while I was thinking in that mode, which made each one more efficient to develop. Later on I got an efficiency by not having to context switch from the web end back to the Hibernate end to build a new one. I think my approach was sensible, or at least it worked well for me. As I read the XP canon, what I did violates the precept. True, I could have found out that some of the JDOs were not needed from the web end, but by doing all that work at once I got an efficiency that negated that risk. By not having to do them later, it reduced the frustration load at a point where I needed it as low as possible.

That's just an example, but a very current one. I work on this project every day so all the details are fresh. I think I'm working in a way optimized for the way I think. If I can squeeze more efficiency out of it, I want to, which is why I'm looking to see what XP can offer me. I'm beginning to think that I may have already mined everything out of it that I will find useful.

Thanks for your reply.

d