I personally would like to start adopting XP practices with Avalon. I believe that it fits the open source development style very well. The thing is we have several challenges ahead of us to get it done. Not the least of which is the change in mental framework that we have to go through.
We do not all need to come to agreement that this is the way to go for working with Avalon code, but there are some lessons to be learned from it. I think things will go smoother once we come to grips with these lessons. The observations are mine, so feel free to take them with a grain of salt (please refrain from comments to that effect... ;P )
Anyway XP practices include:
* Test driven development. Write tests before code. That way you know your requirements are measurable, and that code needs to be written (you might find your current system can handle the new requirement without change).
* Do the easiest thing to satisfy a requirement. Why waste time and effort properly implementing a finite stage machine when a couple of simple if/else statements will do the job?
* Refactor mercilessly. When the if/else statements are no longer the easiest thing, they should be replaced with something that is. As we refactor mercilessly we learn code "smell" and can attack systemic problems more easily.
* No big design up front. While we have a general requirement, we don't have all the information we need at the beginning to properly specify it. Don't. As we find something that works, we can specify it then. In general, hard requirements should be avoided.
* No attachment to specific methodologies. Just because our idea works today doesn't mean it will tomorrow. (Remember the points from no big design up front). Don't fight tooth and nail for a way of doing things--more than likely it will be replaced with something that works better later.
So what does this mean as far as it affects us?
* We will have better test coverage (for the essential stuff we are ok). * We will have fewer hard positions. What is easiest for us here is to identify interface/implemenation. We should take advantage of that. * We will spend less time arguing about the name of something and more time doing. (more fun).
That said, I think that some of us are so ingrained with the big design up front mentality that they don't realize how much it is impacting Avalon. I probably fall into this category myself. It isn't easy to allow designs to evolve. The more practice we have at it the easier it will become. We also have some specs that need to be supported. We will need to do that for as long as Avalon 4.0 is supported.
Let's start working towards middle ground much sooner, which probably means that those points of contention need to be addressed uniquely. For instance, address some issues can be solved by applying our SoC design pattern. Implementation is far less important than interface. Interface should start simple and only be expanded when it is absolutely necessary.
Remember, let's do the simplest thing to resolve an issue.
--
"They that give up essential liberty to obtain a little temporary safety
deserve neither liberty nor safety."
- Benjamin Franklin
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
