Software Process (was Re: Concurrency)

[glen e. p. ropella]

Philippe LAVAL writes:
 > I do not know how big is the core Swarm library. What I know is that in
 > a large project, in addition to design problems, if there are more than
 > 2 programmers you are likely to also encounter software management 
 > problems. They will not be solved by a language choice, but by the use 
 > of a development methodology, together with management skills.

Just to add my two sense [grin]... I think it is very important for
Swarm (the project) to start outlining some software design
methodologies right now.  Of course, as with everything else, the lack
of resources dictates what gets done and what doesn't.  But, Swarm is
sufficiently complex to be sensitive to slight changes in some
functions in the so-called kernel.  This doesn't mean that it's not
robust.  But, it does mean that it's difficult to change or add
functionality in a non-patchwork fashion.  One has to be an expert in
order to add or change the functionality of the kernel.

This is bad.  Right now, what this means is that the persistence of
the package depends (in some weak way) on the persistence of the
writers of the package.  I'd like to move away from that.

And this means that the Swarm project should adopt some software
generation and testing practice and procedure (P&P) guidelines.  We
have some conventions going, at present; but, we don't have a complete
set and the emphasis is a little too light.

With the move of Swarm from a research project to a development
project (symbolized by the move to an entity we've been designating as
".org"), I think it's imperative that some software engineering
practices are nailed down, documented, and enforced.  And the SE
practices I'm talking about apply *mainly* to the developers of Swarm,
itself.  But, of course, whatever practices that get implemented at
the developer level would probably bleed up to the applications level
to some extent.  *So*, it would be nice if the users would help in the
design of such software processes.

This message is already too long.....[grin]... But bear with me a
little longer so that I can give an example of the kinds of processes
I'm talking about.  I recently released 1.0.2 of the Swarm package.
I put in it some modifications to the code that allowed it to run
on the DEC Alpha.  Some of these modifications may not have been 
necessary.  But, since spending time on a change-by-change 
justification process is fairly expensive (in terms of time), I 
opted to just release it after doing my normal test suite, which 
consists of running every application I can get my hands on and 
running each app through an extensive and changing, though not
exhaustive, test of the features available.  And doing each of these
apps on two or more platforms.

Now, the changes that were made to the code that might not have been
necessary for execution on the Alpha can be effectively identified by
either a change-by-change justification process or code walkthroughs
with other cognizant developers.  Both of these are expensive; but, if
they were nailed down as a mandatory part of our software process,
then the option of skipping them would not exist.  So, I think it
*ought* to be a part of our process.

Unfortunately, they're too expensive, at present.  If I make the
change, and I'm the only one who is allocated to full time development
of Swarm, then some compromise has to be reached.  What might the
alternatives be and how should they be implemented, etc.?

That is the kind of question that needs to be answered for the 
development stage of Swarm.

glen
-- 
{glen e. p. ropella <address@hidden> |                                  }
{Hive Drone, SFI Swarm Project         |            Hail Eris!            }
{http://www.trail.com/~gepr/home.html  |               =><=               }


                  ==================================
   Swarm-Modelling is for discussion of Simulation and Modelling techniques
   esp. using Swarm.  For list administration needs (esp. [un]subscribing),
   please send a message to <address@hidden> with "help" in the
   body of the message.
                  ==================================