RE: VisualAge for Java

I have to disagree with some of Joe's statements, too.  We installed VAJ
Enterprise in our environment; at first there was only me using it, so after
I installed all of our classes in it, they all belonged to me.  Then our
second programmer came back from the training course.  He's more of a
beginner than me, so I started him off with changing some things in MY
classes.

Now Joe says "Instead, all requirements should be given to the class's
owner, who should implement them."  Well, no.  That would mean I could only
give the new programmer complete classes to write, which is too much for a
beginner to attempt.  In most development environments, requirements for
changes often arise that are reasonably simple for anyone to implement;
there should be no management rule that requires the class owner to
implement them.  VAJ Enterprise does require the class owner to approve
them, and that's a perfectly reasonable rule.

Right now, with only two people using it, the management of VAJ Enterprise
isn't too bad; it's just a matter of shouting over the cubicle wall "New
version of Package X!".  But I can see that for an environment with a dozen
programmers, one of them would have to be designated as Source Control Czar
and spend a lot of time chasing people to update their versions with
everyone else's work.

PC2

-----Original Message-----
From: Jim Mason [mailto:JEMason@compuserve.com]
Sent: May 13, 2001 10:25
To: INTERNET:JAVA400-L@midrange.com
Subject: RE: VisualAge for Java


Joe.

There is a REAL model for management of classes.
It DOES allow for concurrent access.
It also allows, if needed, for split thread development where necessary.
Source control tools only go so far in managing the development process.
You have to understand fully the management model to use the tool
correctly.
VisualAge Enterprise edition or other 3rd party tools that can integrate
like RCS etc do require developers to understand the management model to
use them successfully.

The VisualAge Enteprise model DOES support class ownership, package
ownership and project ownership, separately if needed.  It also supports
collaborative development within that context...

Jim Mason


Message text written by INTERNET:JAVA400-L@midrange.com
>
RE: VisualAge for JavaIn my opinion, the idea of two people working on the
same class is in itself flawed. The whole idea of a class is for it to be a
small, self-contained piece of code whose inner workings are controlled and
owned by a single person. Of course, someone else should understand it, in
order to avoid the "hit by a bus" situation, but the idea of two people
independently modifying the same class at the same time is, to my thinking,
wrong for a number of reasons:

1. No class should be big enough to require that two people make
simultaneous changes. Instead, all requirements should be given to the
class's owner, who should implement them. Simultaneous modifications
without
central management is a recipe for disaster in any software project.

2. A class may have side effects within it that one programmer knows and
the
other doesn't; this is the nature of object-oriented programming. No user
of
the class cares about the side effects, because their only contact to the
class is thorugh the interface, but anybody actually changing the code may
not know the ramifications and break something.

3. Unless there is a standard test suite that one can run a class through
to
ensure that it is not broken, nobody should change someone else's class.
Since objects have state, you must test the various states, and any class
large enough to require multiple programmers is going to have many, many
possible states.

People who insist on running distributed development projects using project
management techniques that made sense for monolithic green-screen
programming are missing the point - object-oriented, dsitributed
development
is a completely different environment than I grew up with in the
traditional
midrange platform.

Joe
+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---