Re: Work Distribution

On Wed, 6 Jan 1999, Per Mathisen wrote:

> On Tue, 5 Jan 1999, Sebastian Fischmeister wrote:
> > That's absolutely right. There has to be a big design phase ( UML
> > for structures, GUI-planning, third-party source evaluation), before
> > we begin with coding.
> 
> I am sorry, but I really don't think design-by-email is going to work very
> well. If you think the present design can be made better, then go ahead
> and suggest a better design by example. I've seen to many examples of
> failed design-by-email to believe it can work.

Well I did start on doing this.  But a design framework should not just be
a patch to some badly designed code (no offence!).  So I started all
over, started on the framework from scratch.  But even with the tiny
amount of code that existed (exists) there were no interest in just
accepting new code.  It had to be patches to the existing code.
If this is how we will do things now, I will not like it when much
more code exists.  If you cannot things you don't like away, you will
not be able to make things much better.

But I think I must aggree with you.  Design via e-mail is not the
best idea.  Especially if to many people are involved.  But maybe
two people can make a good design, with the help of diagrams....

One thing I _do_ know is that I don't want to spend time on a
project like this if it is done as a lot of random hacking, instead
of a lot of hacking around a nicely designed framework.

> > Esp. well known design patterns should be used, to ease reuse and help
> > other 'join' the coding phase. (eg.: factory-pattern for units and
> > maptiles, singleton-pattern for general options, etc...)
> 
> On the other hand, such design patterns may actually make the code more
> complicated and therefore harder to understand :)

It shouldn't.  But if you don't much experience with design patterns,
you might be in for a good experience ;-)
It can take some thinking to understand the idea of a design pattern
the first time you use it, but the end result it just much better,
and it will IMHO make the code much more readable.

> > We could use 'dia' for UML.
> 
> ...and what does that mean in plain English?

UML = Unified Modeling Language.
It is _the_ modeling language for OOA/OOD.  All Java code should
of-course come from a OOA/OOD proces, and UML is simply the way
to do this.


-- 
/Esben  ([email protected])

Obviously I was either onto something, or on something.
             -- Larry Wall on the creation of Perl