× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: RE: VisualAge for Java
  • From: "Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>
  • Date: Sun, 13 May 2001 14:36:57 -0500
  • Importance: Normal

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.
-----

Sorry, but this doesn't change the point: you should never have two
programmers in the same class at the same time.  In your case, you are
temporarily transferring ownership to the new guy, not opening it up for
both of you to be making modifications at the same time.  Allowing one
programmer to temporarily own a class is fine.  Having two programmers
working in the same class at the same time is bad.  You're doing the former
(I hope).  If, however, you're making changes in a class at the same time
that the "new programmer" is, you're defeating the purposes of sound
development, and sound teaching.

Anyway, this example does not, in my mind, argue for concurrent development.
However, we're treading dangerously close to the opinion neighborhood, where
all viewpoints are valid, so I'm content to let this drop.  If you ask me,
there is no good reason for two developers in a single class at the same
time, ever.  There are occasionally reasons of expedience that require this,
but never, never should it be part of the regular development.  If you want
to argue this in more detail, feel free to drop me an email.

Also, this argument may not hold depending on your design philosophy.  My
largest class is 500 lines long, with some 200 lines of that as comments.
My median class size is under 100 lines of code.  This makes it almost silly
for two developers to ever be inside one of my classes.  If your class size
is regularly 1000's of lines, then you will have a different development
methodology.  However, any Java class over 1000 lines of code needs to be
carefully reviewed.  Take as an example IBM's Java Toolbox for the AS/400:
though it has some 1500 or so classes, only about 50 (or 3%) have over 1000
lines of code (including lots of comments).  Interestingly, the majority of
those classes are either JDBC support or visual access.  And even with those
huge classes, the median class size in the tool box is around 150 lines
(again, including comments).

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
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.