Surviving a new team and opinions on their framework

Question

I have recently moved to a new development team tasked with using and improving their existing application framework. I've isolated a dozen areas that misuse Struts and demonstrate a lack of proper object-oriented techniques. Unfortunately tempers flair and members of the team vehemently defend their system when I point these out and I have had little encouragement from above. Are there ways to handle this situation?
For my own reassurance, I ask those of you whose experience surpasses my own to point out the flaws in the following samples of what I've found. The architecture consists of a webapp to respond to user requests as well as numerous (sometimes 6 or more) other webapps serving a middleware role. Communication between webapps consists of capturing the responses of chained http get or post requests:
1) Requests of the back-end webapps all hit the same actionmapping and use the same actionform. That uber form bean either contains every attribute to handle all possible requests or it contains generic parameter names that can be used as needed. When a request comes in, a factory uses one of these parameters (serviceid) to determine which so-called "component" (worker-class) to instantiate to do the processing (if serviceid=foo, component=bar).
2) On the front-end webapp, requests are mapped to different actions which provide an accessor method to obtain an instance of another class that does the work (again, a "component" class). That class contains a method called "getStyleSheet" to return the hard-coded name of the one page the user should be shown for this request. All actionforwards for all actionmappings point to a single transform servlet that uses this method to send the user to the one view that is available for their request. The stylesheet then watches for an error element in the xml doc and displays alternate html.
3) Front-end requests come into an action object that pushes the processing off to a "component" class. The superclass "component" reserves a connection from the database. The implementation "component" class then interrogates the parameters to determine if the necessary parameters were provided before adding error codes to the document, releasing the db connection and sending the user to the style sheet. * The actionform does not encapsulate its own validation capability (or make use of actionerrors) and * database connections are reserved before we're sure it will be used.
4) The webapps demand that every actionmapping be associated with an actionform, even when no form exists. The superclass of all actionforms in this system drops the configuration settings into itself and later the user's form implementation is serialized as xml as part of the document to be transformed. Image and action paths are examples of parameters obtained this way.
That's enough of my pain for now. Any opinions on the above methodologies or suggestions for handling this situation are appreciated.
- Dave

Answer 1

Dave, from your description, this sounds like a complicated system. At least insofar as my experience is concerned, most of the so-called o-o systems that have come my way (usually because they have problems) are actually "object-disoriented". However, telling someone that their implementation is not quite up to par usually causes the other person (or persons) to get defensive. Somewhat of a lioness and her cub syndrome, if you will. Almost everyone I've ever worked with believes that their design and/or code is the best in the world and that it is impossible to improve it. There are precious few who are truly open to suggestions and improvements.
IMVHO, your best bet is to get to know the people on the project, so that they start trusting to you to some extent, esp. if you're a consultant and they're not. It would be wise to understand why someone designed and/or implemented a particular component the way they did.
Another point to understand is the exact, precise reason why you were brought into the project. Does the management think that the existing team lacks experience? Or that the performance of the team/app needs to improve? These are the situations in which I've found myself more than I care to remember. My approach has been to let the team members know that I'm there to help them out with things I've learnt through my own as well as others' mistakes. When I do find things that, frankly, stink, I usually point out some example (from another situation) and get them to think differently. When they do move in the right direction, I encourage that train of thought. Above all, as a consultant, I make sure that the team members get the kudos.
Here's are a couple of books that may help you and the other folks on your team.
Object-oriented Application Frameworks
- Ted Lewis, John Vlissides, Wolfgang Pree, Erich Gamma & Larry Rosenstein.
Design Patterns: Elements of Reusable Object-oriented Software
- Erich Gamma, Richard Helm, John Vlissides & Ralph Johnson.
In addition, copies of periodicals such as Java Pro, Java Developer's Journal, etc. circulated in the team may help them understand how they can improve.
All the above presupposes on thing - that the team members, at least to some extent, are open-minded. As the saying goes, a parachute and the human mind are alike in one respect; both work well only if they are open.
Good luck to you!
Cheers!