Re: OO and Procedural Work Units

> I'd love to hear other's opinions on this, especially anyone who's done
> production Java and RPG/ILE (real ILE) programming on similar systems.

Hmm Im not a programmer, but do have some experience in both types of
projects.
In this case we're talking about two projects running in the same
organisation. They do deal
with different areas of the business, but they were both large projects.

(a) The OO code quality exceeded the procedural.   In fact so much that the
value of this alone
outweighed the re-use value.

So I think your units may be right from a programmer measurement, but I
think they get closer when
you add test/fix resources.

(b) In the project there is a tendancy to overuse inheritance. The impact of
such is there is
considerable loss of flexibility.  Business changes can/do break the model
which causes
significant impact.

(c) The tools are not a substitution for skilled people.

I've seen a few comments about the identification of recurring code as being
an indication of pattern
recognition. While thats true I think patterns at the design level are far
more effective that patterns at the code
level.

 (d) The OO work was much easier to implement a staggered delivery approach
based on function than the
RPG approach.

Users got access to working business function faster than the RPG
development. So while
the effort may be greater, I think the overall elapsed time to delivery is
potentially reduced. (Since the projects dealt in
different domains, this is really a gut feelling more than fact)

(e) In our case we found tools for managing the development process to be
more mature in the ILE environment.
We needed to employ a number of toolsmiths to support the application
development process. (Note the Java is
fat client application deployed within an organisation across a number of
geographic locations. So some of the infrastructure
is required simply for sw distribution. This would not be the case in a JSP
framework, but this projected started 3 years ago so
JSP was not an option.

____________________________________________________________________________
__________________________________
> but don't miss out on the fact that one's procedures (functions,
> classes, whatever your favourite term) can and should be
cross-application.

It may be semantics but I would disagree with this statement.  IMO
classes/functions really are
too granualar for cross application requirements.

I think there are different levels of granuality

     1. Objects
     2. Components
     3. Services
     4. E-Services.

Typically a service oriented framework would be more suited to cross/inter
applications within an
organisation.  With an e-service being cross orgranisation (example would be
HP's E-Speak)

> I fight every day to get programmers to stop thinking about "this program"
> or "this problem" but to expect that somebody else could use the routine.
> Broaden one's outlook, so to speak.  It takes only a little more time to
> make the function more generic and the payback can be huge.

IMO This is a management problem.  Typically projects are expected to
deliver their function as fast and cheep
as possible.  And that is counter to the approach of taking time and effort
to build a more generic/interoperable
service.

I dont disagree that it only takes slightly more effort and there are
rewards to the organisation.  Its just you need to
somehow inbuild that into the project management framework.

> Because the I/O is handled as parameters,
> you can be 100% certain that code changes won't break other code.  That's
a huge plus.

Devils advocate:  But then the impact on retesting is huge if you change the
common function. !!! The impact of
cross domain dependecies can be significant delays.   Just pointing out that
your implementation plans need to
accomodate a phased use of newer versions of common services.

While this can be through duplication of code or by including a version ID
in the interaction. I very rarely see it done
in the interaction, more people tend to end up with different code levels in
production.



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