spring framework, dependency injection, junit

I just joined a new team which is very different from my old team. I don't want to go into the details too much but it was out of my control.

My old team was very much into using the Spring Framework, dependency injection, and writing unit tests using JUnit.
However my new team is very anti Spring, dependency injection, and unit tests. They had some unit tests but they let them fall into abandonment.

My old team was pretty much a new development team that didn't really do much support other than warranty after a release.

My new team does production support and fixes but also does new development.

I got into a conversation with one of the team members because I was using Spring context XML file.
He was like it's so complex it took me a while just to figure out the project.
This was really counter intuitive because I always thought that proper dependency injection made things less complex. But he likes to press f3 and see everything defined so he can clearly trace from the beginning to the end of the app. He saw it as introducing something overly complex into the application.

He went out of his way to say it was even evil and that we shouldn't use anything that new college graduate wouldn't be able to use. This seems rather silly since we don't hire that many college graduates, they teach mostly theory, and little about practical tools to be productive. I answered him we should use any tools that will make us more productive and writing boiler plate code all the time.


Let me ask this of the reader, do you agree you shouldn't use anything a college graduate couldn't figure out?


It seems now with the newest version most all that the XML is gone from Spring and with JEE 6 there will be less of a need for spring but the concepts are still there.

Here's the benefits of Spring I see:
- Bean life-cycle management
- Promotes Dependency Injection
- Has some nice DAO and Templates for ORM
- Transactions management
- Manages singletons instead of coding them
- Focus writing code you need to instead of boiler plate code
- Has some nice utilities to aid in unit testing (I like the simple JNDI stuff so to eliminate container resource dependencies)


Let me ask this of the reader, is the Spring Framework really that complex and is there a set of problems where it's overkill?


Then he came and asked me if I thought dependency injection was good.
I came back and said yes with the following points:
-It allows you to more easily write JUnit Test Cases externalizing the dependencies
-It allows for classes to be single purpose principal and allow for separation of concerns.
-It's getting built into the Java and JEE specs in the future (not sure which versions but we're not there yet)


Let me ask this of the reader, you see value in dependency injection?


I've gotten my projects setup on the continuous integration server so I can get complexity bugs from both Findbugs and PMD which is the kind of complexity I think we should really be concerned about.

This brings me back to the type of team it is. I'm thinking this is more of a classical programming team where they don't care if they introduce issues in prod because they can just fix them. They spend more time fixing that unit testing which is more costly in the long time. They don't see the connection between the production maintenance bug fixes and the lack of unit tests. This also seems to me the difference is this team is more focused on programming rather than software development. They don't do any sort of code reviews either which really surprises me. Part of me thinks it's the culture that the main guy is getting older and doesn't want to learn new skills to the point he doesn't accept things very easily. He probably never has worked anywhere else in his life and cares very little about changes in the industry and things stay relatively the same.


Let me ask this of the reader, have you been in a similar situation? What did you do?