avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@d-haven.org>
Subject Development Processes that Foster Community
Date Tue, 20 Jul 2004 15:25:43 GMT
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 

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 

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 

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: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message