There are many different development processes out there, each with their own emphasis, strengths and weaknesses. The key thing to remember with a distributed group is that communication and building group knowledge is key. Everyone has their take on the way they like to work, and I refuse to say that as long as the quality of the work is good and repeatable that anything would be wrong.
The realities of open source software is that you are not going to be able to legislate any one development process. Instead you have to look at principles that work and ones that don't.
The Rational tool people and the CMG have come up with this concept of
Model Driven Development (MDD). The idea behind this is that you will
pretty much be able to build a working piece of software based on the models put together in the UML tool. Its a nice idea on paper, and in a local corporate environment it might work pretty well. The main issue
with it in an open source environment is that unless everyone on the project has the same tool and the same model, it looses any effectiveness it might have had. Sure people would be able to look at a model, but models are notoriously bad at displaying contracts or the important aspect of how things are done. Yes, I know that there are sequence and collaboration diagrams, but they aren't effective at the level of detail required to maintain code.
The "eXtreme" (or Agile) Programming folks have a set of principles that work remarkably well in a distributed environment like open source development. The reason is that those principles emphasize communication. There may be some models created, but they are at a high enough level to document the major contracts. Most important is the principle of Test Driven Development. When tests drive the development process, you not only spend less time debugging, you also have a working example of how a method is supposed to be used (or how it is not supposed to be used if you are doing bounds checking validation). These examples provide an invaluable big picture view of how it is supposed to work. It also means that it is easier to refactor things and not break anything.
For most of us there is nothing new here.
Now, consider for a moment the process of developing a specification. We really don't have a specification beyond Avalon Framework yet because of the disconnect above (and social issues, but that gets back to communication). Too often we (I'm including me here), have argued about what we would like to see (this paragon of a framework), and have done
it from the perspective of the model of a component, that it was hard to see how it would concretely affect the user. It isn't until you have an implementation that things move out of model/idea and into reality.
If we had created a set of tests that showed what contracts we would have wanted for the component model, we could have come to more concrete data as to what required more work or at least how to come to a compromise.
To be sure some issues were bikeshedding. I remember a long drawn out discussion on whether Initializable.initialize() should be init() or initialize(). You can see what we eventually decided on. However,
something that I started to learn is that people think and operate differently.
If we were to go with the XP approach, we would have realized that the social energy to come to agreement for initialize() vs. init() would be too great and we would have come up with an approach to accept both. Why? Because it was the easiest thing that would get the job done. "But this isn't the best thing from a technical standpoint," you say. True. But technical issues are not the only issues that can hold up a project. Choice is a powerful way to get around disagreements. If it
takes a certain amount of social energy to try and convince someone else of the merits of your argument, then either the argument isn't compelling, or there is an alternate means to satisfy both sides of the argument.
The long term approach should be to enable developers to do what they need to do. The more people force an approach the less friendly the library/project/etc. is. There is more than one way to skin a cat. Why outlaw all methods that don't agree with yours?
--
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."
- Rich Cook
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
