Consolidating java objects

[Dave]

I have been a J2EE developer since Jan 2000, and have been on a number
of projects. However, with most of the projects we have been able to
keep the number of objects that can be used fairly small, to around 50
at the most and re-used or inherited from the core group of objects.

I am now on a project where the number of objects keeps growing with
each development release. It went from 250 to 277 objects in the last
release. There are so many objects that developers no longer look to
see if an object will work for them, they just create a new one from
scratch.

Some objects are small, around 4-10 fields, others are much larger
(dozens of fields) and some inherit from other objects. I cannot come
up with a good way to find the similar objects so that the number can
be brought back under control. I also cannot come up with a good way
for developers to find objects that have what they need, since they
have spread the objects out from the initial framework package into
packages and modules all through the code. A way to compare objects
would also be very helpful.

The project is larger, around 15-25 developers at any time, but I am
tasked with figuring out a solution to this problem. I have tried a
spreadsheet, but it grows too big in a short time, and I can't see more
than 1-3 objects on the screen at once, when I need to be able to see
more of them. I also tried writing an XML document but it was too
hard. Javadoc generates too many files for this to be useful as well.


I have found several examples where the object wasn't needed and a
framework object could be used. I've also found cases where the object
simply extended another object and then didn't add any additional
fields. There have also been cases where the same set of fields show
up in object after object.

Does anyone have any ideas of tools or methodologies to use that could
help? I tried google and yahoo but didn't have any luck. Any ideas
would be greatly appreciated.

Thanks in advance

 

[Robert Klemme]

I have been a J2EE developer since Jan 2000, and have been on a number
of projects. However, with most of the projects we have been able to
keep the number of objects that can be used fairly small, to around 50
at the most and re-used or inherited from the core group of objects.

I am now on a project where the number of objects keeps growing with
each development release. It went from 250 to 277 objects in the last
release. There are so many objects that developers no longer look to
see if an object will work for them, they just create a new one from
scratch.

Are you actually talking about objects? It seems more that you mean
"classes" instead.

Some objects are small, around 4-10 fields, others are much larger
(dozens of fields) and some inherit from other objects. I cannot come
up with a good way to find the similar objects so that the number can
be brought back under control. I also cannot come up with a good way
for developers to find objects that have what they need, since they
have spread the objects out from the initial framework package into
packages and modules all through the code. A way to compare objects
would also be very helpful.

What about documentation? Is there proper JavaDoc and package
documentation?

The project is larger, around 15-25 developers at any time, but I am
tasked with figuring out a solution to this problem. I have tried a
spreadsheet, but it grows too big in a short time, and I can't see more
than 1-3 objects on the screen at once, when I need to be able to see
more of them. I also tried writing an XML document but it was too
hard. Javadoc generates too many files for this to be useful as well.

The question is what is the criteria for identifying similar classes?
If it is just methods or fields that seems pretty easy - even with
reflection. But if you are talking about semantics or want to compare
method behavior then you'll have a difficult task to do.

I have found several examples where the object wasn't needed and a
framework object could be used. I've also found cases where the object
simply extended another object and then didn't add any additional
fields. There have also been cases where the same set of fields show
up in object after object.

Does anyone have any ideas of tools or methodologies to use that could
help? I tried google and yahoo but didn't have any luck. Any ideas
would be greatly appreciated.

First of all 270 classes is not really much. You might be more
successful with a social solution instead of a technical one. For
example, you can improve communication by having developers present what
they developed so others know about. Or you install a process that must
be followed during creation of new classes and which might ensure people
find and use solutions done by others etc.

Kind regards

robert

 

[Daniel Dyer]

I have been a J2EE developer since Jan 2000, and have been on a number
of projects. However, with most of the projects we have been able to
keep the number of objects that can be used fairly small, to around 50
at the most and re-used or inherited from the core group of objects.

I am now on a project where the number of objects keeps growing with
each development release. It went from 250 to 277 objects in the last
release. There are so many objects that developers no longer look to
see if an object will work for them, they just create a new one from
scratch.

Do you mean classes rather than objects?

250 classes is not that big a project (unless they are all huge monolithic
things), especially for such a large team.

Some objects are small, around 4-10 fields, others are much larger
(dozens of fields) and some inherit from other objects. I cannot come
up with a good way to find the similar objects so that the number can
be brought back under control. I also cannot come up with a good way
for developers to find objects that have what they need, since they
have spread the objects out from the initial framework package into
packages and modules all through the code. A way to compare objects
would also be very helpful.

This really comes down to organisation and communication. If you can
reorganise your packages, and which classes are in them, to be more
logical it should make things easier to locate. Ideally, you'd get the
whole team to agree on how things are to be arranged, then everybody knows
how things are supposed to be organised.

The project is larger, around 15-25 developers at any time, but I am
tasked with figuring out a solution to this problem. I have tried a
spreadsheet, but it grows too big in a short time, and I can't see more
than 1-3 objects on the screen at once, when I need to be able to see
more of them. I also tried writing an XML document but it was too
hard.

Something like a UML class diagram would probably be more appropriate, it
will also show the relationships between classes. Many tools will
generate a diagram for you from source code (though it may need some human
input to tidy it up).

Anything that exists in isolation from the codebase is going to be awkward
to maintain and will quickly become out-of-date and useless.
Reports/diagrams that can be automatically generated from the code would
be preferable.

Javadoc generates too many files for this to be useful as well.

There are lots of configuration options and custom doclets to control the
kind of output it gives you.

I have found several examples where the object wasn't needed and a
framework object could be used. I've also found cases where the object
simply extended another object and then didn't add any additional
fields. There have also been cases where the same set of fields show
up in object after object.

Again this is communication. It sounds like your developers are working
in isolation, trying to get their little piece done without considering
the bigger picture. Perhaps code reviews would help?

Dan.

 

[Dave]

Thank you for your answers.
When a class has private fields, getters and setters and no logic, I
call this an object. It is certainly a class.

There are a couple of other problems that I have not mentioned. Half
of the project is offshored to India, and the other half of the
development is done in-house by additional Indian developers and then I
have come into the picture. I would be staying long term and
maintaining what is being written now in addition to doing further
development.

They are not doing any documenting, adding JavaDoc, etc... When asked
to help document their objects so we could see what their objects are
doing/used for, one of the team leaders outright refused and said they
didn't have time for that. Since my boss apparently allowed this,
there won't be any documentation for that.

We have plenty of instances where there are 3-4 classes (objects) named
exactly the same, but with completely different fields and each is in a
completely different module or package. How would anyone know which
student class to use without any documentation or JavaDoc?

Reorganizing is easier said then done. There may only be around 280
classes (objects), but we have a few hundred JSPs, a very large number
of services and data access objects that all depend on them. Everyone
is acting fairly independently and without documentation they are
creating classes rather than re-using.

Can you recommend any UML tools that would do this?
Also, I am working towards doing code reviews. Unfortunately, it is
only because I am pushing for it and it will be coming fairly late into
the development process.

 

[Mark Jeffcoat]

Some objects are small, around 4-10 fields, others are much larger
(dozens of fields) and some inherit from other objects. I cannot come
up with a good way to find the similar objects so that the number can
be brought back under control. I also cannot come up with a good way
for developers to find objects that have what they need, since they
have spread the objects out from the initial framework package into
packages and modules all through the code. A way to compare objects
would also be very helpful.

I suspect that if I looked at your project, I'd suggest breaking
up some of the larger classes (dozens of fields?) into smaller
classes with fewer responsibilities.

That's clearly not the direction you want to go.

What difficulty is having too many classes causing? Alternately,
what Good Thing would you gain by having fewer classes that you
don't have now?

 

[Daniel Dyer]

Thank you for your answers.
When a class has private fields, getters and setters and no logic, I
call this an object. It is certainly a class.

There are a couple of other problems that I have not mentioned. Half
of the project is offshored to India, and the other half of the
development is done in-house by additional Indian developers and then I
have come into the picture. I would be staying long term and
maintaining what is being written now in addition to doing further
development.

They are not doing any documenting, adding JavaDoc, etc... When asked
to help document their objects so we could see what their objects are
doing/used for, one of the team leaders outright refused and said they
didn't have time for that. Since my boss apparently allowed this,
there won't be any documentation for that.

OK, this doesn't sound like much fun.

We have plenty of instances where there are 3-4 classes (objects) named
exactly the same, but with completely different fields and each is in a
completely different module or package. How would anyone know which
student class to use without any documentation or JavaDoc?

The short answer is, without documentation, you don't know. If there are
two classes with the same name and neither is documented, the only real
solution is to document them somehow.

There are tools for finding duplicate code in projects (see
http://checkstyle.sourceforge.net/config_duplicates.html) but it doesn't
sound like these will be much help.

Reorganizing is easier said then done. There may only be around 280
classes (objects), but we have a few hundred JSPs, a very large number
of services and data access objects that all depend on them. Everyone
is acting fairly independently and without documentation they are
creating classes rather than re-using.

An IDE with good refactoring support (such as IDEA) should be able to
resolve all of these dependencies for you when doing the reorganisation.
Just make sure everybody has checked-in their changes, declare a temporary
code freeze and then checkout the code on one machine, make the necessary
changes and commit them (in theory).

Can you recommend any UML tools that would do this?

Most of the ones you have to pay for (i.e. Rational Rose, Together,
etc.). I think even the Open Source ArgoUML (http://argouml.tigris.org)
does it (if not, it's commercial cousin Poseidon -
http://www.gentleware.com - will do).

Also, I am working towards doing code reviews. Unfortunately, it is
only because I am pushing for it and it will be coming fairly late into
the development process.

Good luck. I was on a project last year where development took place in
three different timezones, so I know that remote coordination can be very
difficult. I'm glad that my current project team are all in the same room
as me. Even the guy who runs a separate project that we have to interface
with sits next to me.

Dan.

 

[Mark Jeffcoat]

Thank you for your answers.
When a class has private fields, getters and setters and no logic, I
call this an object. It is certainly a class.

That this sort of class should exist at all is a red flag--
it usually indicates you've got a lot of old-school procedural
programmers who are just faking the whole OO thing. Using
getters and setters, instead of just admitting it's a C-style
struct and making all the fields public, means they're probably
not aware of it.

(Of course, "old-school procedural programmers" got a lot
of good software written. It's just useful to know who you're
dealing with, now that a lot of them have migrated to Java.
In syntax, at least.)

They are not doing any documenting, adding JavaDoc, etc... When asked
to help document their objects so we could see what their objects are
doing/used for, one of the team leaders outright refused and said they
didn't have time for that. Since my boss apparently allowed this,
there won't be any documentation for that.

Another red flag, as you're well aware.

We have plenty of instances where there are 3-4 classes (objects) named
exactly the same, but with completely different fields and each is in a
completely different module or package. How would anyone know which
student class to use without any documentation or JavaDoc?

Student class? Is that the domain model slipping out?

If the fields are different, and there's no logic, there's
no real commonality between the classes. This is not a sign
that you have too many classes, but that the separation between
modules isn't doing enough to help manage the project's complexity.

Reorganizing is easier said then done. There may only be around 280
classes (objects), but we have a few hundred JSPs, a very large number
of services and data access objects that all depend on them. Everyone
is acting fairly independently and without documentation they are
creating classes rather than re-using.

Another red flag. That is, that no one's looking for opportunities
to build better abstractions.

Can you recommend any UML tools that would do this?
Also, I am working towards doing code reviews. Unfortunately, it is
only because I am pushing for it and it will be coming fairly late into
the development process.

You don't need a new tool. You've got a broken development
process. Someone in project management must recognize this--that
seems to be why you were brought in.

Code reviews won't help unless your team has some basic agreement
on the difference between good code and bad. For instance, your
definition of good code includes "has documentation", and it seems
that most of the rest of the team disagrees, or just doesn't care.

You're in a tough spot. If everyone continues working as they
are right now, with their current values, they will continue
to get the same results, no matter what new tools you introduce,
UML and otherwise.

(Yeah--no actual Java programming in this post, but I've spent
the last year on a project that once had very similar problems.)

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

I am now on a project where the number of objects keeps growing with
each development release. It went from 250 to 277 objects in the last
release. There are so many objects that developers no longer look to
see if an object will work for them, they just create a new one from
scratch.

Some objects are small, around 4-10 fields, others are much larger
(dozens of fields) and some inherit from other objects. I cannot come
up with a good way to find the similar objects so that the number can
be brought back under control. I also cannot come up with a good way
for developers to find objects that have what they need, since they
have spread the objects out from the initial framework package into
packages and modules all through the code. A way to compare objects
would also be very helpful.

As other has said then this is not that many classes.

That of course does not prevent it from being a mess.

But I doubt any tools will solve the problems.

You will simply have to look at the classes, see where
they are used, see what they contain and do the refactoring
the hard way.

Arne

 

[=?ISO-8859-1?Q?Arne_Vajh=F8j?=]

That this sort of class should exist at all is a red flag--
it usually indicates you've got a lot of old-school procedural
programmers who are just faking the whole OO thing. Using
getters and setters, instead of just admitting it's a C-style
struct and making all the fields public, means they're probably
not aware of it.

Or they may have read a book about J2EE (including the
section about DTO pattern).

Arne

 

[Mark Jeffcoat]

Or they may have read a book about J2EE (including the
section about DTO pattern).

I agree-- in one version of my post, I included as a footnote
the idea that the dev team may be something clever to
deal with the accidental difficulties of J2EE.

I deleted it. I don't see any evidence from the original
poster that his team is making sophisticated decisions, and
I decided not to confuse the issue.

(No insult intended. I don't think your point is wrong, I'm
just moving toward the idea that talking about "patterns"
to people who haven't gotten a good grip on the basics may
actually be counter-productive.)

 

[Chris Uppal]

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

 

[Dave]

Thank you all for your answers, they are very helpful. Unfortunately
the developers I am working with have come from the schools in India
where they teach you the syntax but you don't know how to really apply
it. They've worked a few months or a little longer at other projects
but are not really medium to high level J2EE programmers. I narrowly
averted our initial Production rollout from being a disaster when I
found in some code they weren't handling JDBC connection resources
properly (or at all), and then had to do a rapid scan of a few hundred
long DAOs, list everywhere it wasn't handling connections properly, get
it out to the team leads and then with management behind me, forced the
changes to be fixed over a week. I then verified every single one of
them. Up to that point they had been having max cursor errors
constantly during load testing but hadn't told me until I found that
out. There hasn't been one since.

I have been doing this type of development for over six years now, and
have a list of around 20 best practices that I do my code reviews on.
I used to have closer to 30, but I updated it a couple of months ago
for JDK 1.4.2. The goal is to start out with me doing a few initial
code reviews, then have the team leaders start doing them as well, and
get to the point where the developers are doing them for each other. I
have also installed Hammurapi, customized the inspector list and
modified existing inspectors and am running those automated code
reviews once a week. The violations are starting to get fixed more
now.

But they aren't experienced and do not make sophisticated decisions.
In fact, if it is not written out in a functional spec, they will not
even go ask the question. They will just make an assumption (usually
wrong) and it isn't caught until the QA cycle where it becomes a defect
and then the spec gets updated. I'm trying to get some of them to just
go ask the question, but it is hard.

I never bothered with getters and setters that didn't have logic either
in my previous projects. I knew a heavily OO guy whose code was pure
OO. I remember him having lines like this:
getSomeFactory().getSomeClass().getSomeMethod().getSomeField()
..getSomeOtherField().getSomeList().getSomeField().getYetAnotherField().setSomething()

And sometimes he'd have fifty or sixty lines like that in a row. No
one could ever follow
the logic. And every method was just a pure getter, no logic at all.

Also, I am quite familiar with the various patterns, I have Design
Patterns and have used quite a few of them, and have also passed the
various Sun J2EE certifications, including the J2EE Architect
certification.

The number of objects may not be a problem, but part of Java is the
idea of re-use. When I see the exact same 10 fields over and over in
dozens of objects, that looks to me like there should have been a
single class with those 10 fields, and all of the others should have
inherited from that class. And considering that back in January there
were only around 30-40 classes (from the current project architect) and
that now we have 240 more just 9 months later looks to me like out of
control object creation, especially when so many are so similar in
various ways.

 

[Dave]

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.

 

[Dave]

In one of the extreme examples, one of the 'simple' classes I looked at
yesterday (just fields, getters and setters) without any logic, was
1560 lines. Fun, eh? That one is pretty extreme though.

The problem isn't as much the number, as how to get the developers to
re-use what is there when it is scattered everywhere, not named
properly, not documented and they don't make much of an effort to look
for a class to re-use or inherit from unless you make it really easy
for them. It takes them five minutes to create a new one, so they all
do that instead. In one month we added 30 more.

So I am trying to get a handle on this by trying to find a way to
reduce the number of classes to a more manageable level and would like
to bring them all back into a few packages in our framework module.
But figuring out a good way to do this a hard problem, so I thought I
would try this group to see if anyone has dealt with similar problems
and how they resolved it. The answers have been very helpful, so I
will probably have to try looking into the UML software to see if it
will help.

I would love to have all of their current relationships mapped out,
have all of their fields listed and fill a wall with it to illustrate
to the developers what they are doing.

 

[Robert Klemme]

On 17.10.2006 14:40, Dave wrote:
<snip/>

It seems you are on a good track though. Circumstances are certainly
less than ideal but since you enjoying it...

I never bothered with getters and setters that didn't have logic either
in my previous projects. I knew a heavily OO guy whose code was pure
OO. I remember him having lines like this:
getSomeFactory().getSomeClass().getSomeMethod().getSomeField()
.getSomeOtherField().getSomeList().getSomeField().getYetAnotherField().setSomething()

I would not consider that "pure OO". That's plain nonsense. You can
achieve the same level of encryption by nesting function calls that deep
in other languages.

The number of objects may not be a problem, but part of Java is the
idea of re-use.

I would even go as far as to say reuse is a major goal whatever language
you use. OO languages are generally considered to be better suited to
facilitating reuse, but you can do that in all languages.

When I see the exact same 10 fields over and over in
dozens of objects, that looks to me like there should have been a
single class with those 10 fields, and all of the others should have
inherited from that class.

.... or used that as a member (delegation).

> And considering that back in January there
were only around 30-40 classes (from the current project architect) and
that now we have 240 more just 9 months later looks to me like out of
control object creation, especially when so many are so similar in
various ways.

I'd like to make two requests: please stop using the word "object" when
in fact you mean "class". This is bound to cause confusion. We have
some terms with pretty clear meaning in CS and it helps communication
greatly if everybody sticks to them.

And please do not top post.

Kind regards

robert

 

[Dave]

I will certainly try not to top post, I apologize for that. It has
been a while since I've used newsgroups so I have to try to remember
the proper posting rules.

I would not consider that "pure OO". That's plain nonsense. You can
achieve the same level of encryption by nesting function calls that deep
in other languages.

He called himself a 'pure OO' programmer, which is why I used that
term. He was also fired for trying to refactor everyone else's code on
that project into the same garbage, and then when I caught it during
code reviews and management and I explained why that was a bad idea for
maintenance, he deleted everything he'd ever written including out of
VSS and then he was fired. Luckily there were recent backups of that
drive.

I would even go as far as to say reuse is a major goal whatever language
you use. OO languages are generally considered to be better suited to
facilitating reuse, but you can do that in all languages.

... or used that as a member (delegation).
Agreed.

I'd like to make two requests: please stop using the word "object" when
in fact you mean "class". This is bound to cause confusion. We have
some terms with pretty clear meaning in CS and it helps communication
greatly if everybody sticks to them.

Sorry, when they are being called DAOs or Data Access Objects and that
is how I hear them called all day long by everyone including our
architect, I've kind of adopted that term. I know it is a class, but
it is a hard habit to break.

And please do not top post.

Did I do any better on this?

Thanks,
Dave

 

[Robert Klemme]

I will certainly try not to top post, I apologize for that. It has
been a while since I've used newsgroups so I have to try to remember
the proper posting rules.

No prob. And: yeah, it is a quite unique community. You'll
probably easy remember once you tried to dug yourself through a lengthy
posting with multiple quotes. )

He called himself a 'pure OO' programmer, which is why I used that
term.

Ah, I see.

He was also fired for trying to refactor everyone else's code on
that project into the same garbage, and then when I caught it during
code reviews and management and I explained why that was a bad idea for
maintenance, he deleted everything he'd ever written including out of
VSS and then he was fired. Luckily there were recent backups of that
drive.
Wow!


Sorry, when they are being called DAOs or Data Access Objects and that
is how I hear them called all day long by everyone including our
architect, I've kind of adopted that term. I know it is a class, but
it is a hard habit to break.

I see. Maybe then stick with DAO - but then again, Microsoft's version
is dead (replaced by ADO, they still have some permutations left ).
But yes, old habits die hard...

Did I do any better on this?

Perfect! Bottom posting and truncated quotes.

I wish you luck - and fun!

Kind regards

robert

 

[Martin Gregorie]

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.

Sounds to me as if the system designer (architects design buildings so I
won't call him that) didn't decompose his design to a deep enough level
to recognize these classes.

The design sounds incomplete. I wonder about the following:
1) was the designer prevented from or unwilling to do that
2) why didn't the programming manager put rules in place for adding
classes to the framework package
3) did the project manager unleash the coders before the design
was complete

Regardless of what happened, it sounds like a mess.

I've been there, done that. A long time back an organization I was in
started two similarly sized projects at the same time. Both were online
database systems that ran on the same mainframe. Mine took the time to
get the requirements, functional spec and the application structure
right before we started coding. The other project rushed those stages
and started system testing while we were still integrating modules for
our first, simplest set of user screens. We got jeered at then, but we
had the last laugh: our entire system was live with additional users
demanding access to it while the other bunch, having failed entirely to
complete system testing, were starting a major redesign and junking code
right left and center. I changed jobs at that point, so don't know what
happened to the other project. Mine was in use for 14 years and only
shut down because its originally mandated platform (COBOL/IDMS/ICL 3900
mainframe) was being replaced with UNIX servers and an RDBMS database.

 

[Martin Gregorie]

The problem isn't as much the number, as how to get the developers to
re-use what is there when it is scattered everywhere, not named
properly, not documented and they don't make much of an effort to look
for a class to re-use or inherit from unless you make it really easy
for them. It takes them five minutes to create a new one, so they all
do that instead. In one month we added 30 more.

Two words Javadocs and cvs.

Can you and your management force them to code to adequately documented
Javadocs standards and place source files in a central source repository
once it clean compiles?

The repository could be cvs, subversion or even PVCS if development is
on PCs rather than a central server.

This would allow you to run an overnight source extract and compilation
against the repository (which may smoke out some more problems ahead of
time) as well as generating Javadocs output and making it available to
the developers via an intranet web server. This would remove their "we
can't find it" excuse for not re-using existing classes as well as
improving documentation.

I would love to have all of their current relationships mapped out,
have all of their fields listed and fill a wall with it to illustrate
to the developers what they are doing.

Using Javadocs, as described above, would be a start.

That will, at least index all publically declared constants, variables,
methods, classes etc. If you need more help it should be simple enough
to do further custom processing on its index pages.

 

[Daniel Dyer]

He called himself a 'pure OO' programmer, which is why I used that
term. He was also fired for trying to refactor everyone else's code on
that project into the same garbage, and then when I caught it during
code reviews and management and I explained why that was a bad idea for
maintenance, he deleted everything he'd ever written including out of
VSS and then he was fired. Luckily there were recent backups of that
drive.

Sounds like you are well rid of him.

Are you still using SourceSafe? That's really going to bite you on the
arse with your developers are working remotely, let alone in separate
timezones. SourceSafe is well... actually not safe for putting your
source in, it sucks for remote access and it cannot handle commits from
different timezones without doing scary things to your repository.

This is required reading:
http://www.highprogrammer.com/alan/windev/sourcesafe.html

An alleged quote from an unidentified Microsoft employee:

"Visual SourceSafe? It would be safer to print out all your code, run
it through a shredder, and set it on fire."

Dan.