The product I spend a most of my time has a number of components, each with a whole bunch of ‘projects’ in eclipse-speak. I spent yesterday and today setting up a development environment for one of them and in doing so uncovered another smell regarding the system as a combined entity.

More than one library for any one function is a symptom of much larger architectural problems.

In this case of this product I noticed there are 4 different ORM systems being employed

  • Component A – this is likely about 85 – 90% of the customer facing product and uses Hibernate2 and TopLink
  • Component B – this makes up the bulk of the remaining customer facing products and uses Hibernate3
  • Component C – is used my internal support staff and uses iBatis

Not only does this fragment developer expertise across 4 different tools (hibernate2 and 3 might as well be separate entities) but it is going to make upgrading of the database even more painful that is already going to be.

What is interesting is that this smell doesn’t actually originate with the software directly instead is actually organizational. Enterprise Architects tend to get a bad rap, but once an application gets to be a certain size they become almost a necessity. An EA with sufficient organizational care and clout could have this unnecessary duplication cleared up in a couple months (wholesale, flip-a-switch conversion would be a bad idea) but I have in 14 months seen exactly one communication from this particular EA’s office and that was a security guideline document that very few developers actually seem to follow.