Re: Consolidating java objects

From what I understand I sort of feel sorry for you, but as you say, it is an opportunity. Just hope you are not going to be frowned upon by the management.

In any case, it seems to me that you need to involve the programmers. They have all the information in their heads (is suspect job security is the culprit), they won't document it but you need access to it. I would try an approach where you try to elicit the real framework information from the programmers, perhaps by a couple of meetings or coffee break chatting, or something. Then you establish what are the central classes being used, or which should be used. You can then start to redesign a proper framework and refactor all the supporting classes from there. But you do need to include the programmers, your work will be wasted. If necessary, teach them how to use it correctly and show them how they can do things more efficiently. That is, unless job security is the real issue here. Perhaps you should start by trying to figure out why they are reluctant document or why they write the crappy code.

tom

Dave wrote:
I hear what you are saying, but I also enjoy the challenge of what I am
facing. I love solving hard problems and working with other people,
and this is actually fun for me. The reason I posted here was because
I have just been having the hardest time grasping a non-time-intensive
way to compare all of these objects to see what is similar. I know one
thing I could just do is open each class and print it, then group
similar objects together in piles. Or I could write something that
would look at all of the classes, pull out the fields and try to
compare each of them to each other to find what is similar.

We had a wonderful framework package in one module that the architect
created where these classes were supposed to go. But he didn't follow
up on this and after three development cycles in 9 months, the
additional 240 classes were created in so many modules and so many
different packages it is unbelievable. Also, the number wouldn't be
that much of a problem if so many of the classes (objects) weren't very
similar in various ways.

I really believe in the product being created, it is for a very, very
good cause. So for that, I want the project to succeed and I want to
be a part of it. If I don't do as much development any more, it is
okay because I get to help solve some very difficult problems which I
enjoy doing.


Chris Uppal wrote:
Dave wrote:

I would be staying long term and
maintaining what is being written now in addition to doing further
development.
If this project is in anything like the state I'm imagining, then I fear that
you are wrong. You may be staying long-term, but it doesn't sounds as though
you'll be doing a lot of "further development".

Here are two specific suggestions.

1) See if you can isolate all the data-only classes, put them all into one (or
maybe several) special packages with names like xxx.dataobjects.whatever; and
see if there's any structure at all in what's left. If you are lucky there
will be some decent structure which the clouds of brain-dead "structs" have
been obscuring.

2) Quit now.

-- chris

.

Relevant Pages

  • Re: About speed
    ... There's two things in the sample: the .NET framework libraries, ... A lot of people thought that one day all business applications would be ... with only lower level coding requiring the power of C++. ... programmers, but by business people. ...
    (borland.public.delphi.non-technical)
  • Re: What Borland should stop wasting their time on
    ... The framework has a lot of promise, but I think Microsoft was far too ambitious releasing far too many assemblies much too quickly. ... As a result design suffered, but to provide backward compatibility, Microsoft could not simply redesign the whole library and deprecate the old one. ... C/C++ programmers are on a different league as .NET. ... This concept is pioneered by Delphi and Java. ...
    (borland.public.delphi.non-technical)
  • Re: Simple 2D framework
    ... that is something that does worry me. ... Which proves you are far far from a beginner and therefore very able to make ... The other thing I am noticing is that a lot of .Net programmers rely on this ... If only the framework was better documented..... ...
    (microsoft.public.win32.programmer.directx.managed)
  • Future of programming
    ... packages in the future. ... inexpensive computers have enough memory, CPU power and disk space to ... Most programmers don't like to write ... custom code, etc.) are still going to require people who have the ...
    (comp.lang.cobol)
  • Re: Future of programming
    ... > packages in the future. ... Most programmers don't like to write ... > for inserting custom code, etc.) are still going to require people ... I do care about whether it has adequate help ...
    (comp.lang.cobol)