Quote from one of the seniors here:

"Build as simply as possible, in case other people don't know what they're doing"

So, instead of using all tools available (I'm trying to introduce using AspectJ), we should build for the least knowledgeable developer and not teach them anything new.

Simple has its place but not at the cost of functionality. Complex can be good as well.

@Jumpshot44 I totally agree. But we also shouldn't sacrifice building the best software we can, just because some devs don't know the tools/frameworks [yet]

I kinda want to side with the senior here, but also to back you up. If the tool is a good one, you should be able to make the case for it. If it solves a problem without introducing a load of technical debt, brilliant!

But everything has its evangelists. Sometimes a person's reason for using something is purely personal preference. Not suggesting that's the case here, but explaining why it's sometimes acceptable to be cautious. I've seen so many projects where tools or concepts have been introduced without the developer skills to support them long term. It can be painful.

@samk Again, 100% agree. I don't think my post was quite clear enough.
I'm not saying use something for the sake of it. I'm trying to use tools and features where they are appropriate. He's saying only use the basic functionality of the language, because everyone knows it already

@linux-colonel Well then I'm totally on your side. But it's a risk-reward question. Suggests the senior is maybe not a confident person and could be using "the team" to cover his own concerns.

What can AspectJ accomplish that vanilla code can't? Is the cost of implementing AspectJ project wide in terms of billable learning curve hours and the time that will be spent on recruitments is significantly better than implementing the same thing in vanilla Java code?

10 years ago we refactored a huge code base to use JBossAOP. Needless to say adding another layer to what is already convoluted OO and Enterprise stack alphabet soup was really painful.

I also recalled struggling with Spring Roo because one of the senior dev was in love with it. With AOP you have to trust those dependencies will be there during compile time. Unless of course everybody use an IDE tailor made for it.

There is a reason why AOP didn't really take off. It adds another layer of complexity that people don't really need.

@azzuwan by that logic is there any reason for using anything other than vanilla code?

I wouldn't want to refactor the whole code base to use AspectJ, just use it where it makes sense.

Not sure what you mean about the dependencies being there at compile time. I don't want to bring in Load Time Weaving if that's what you mean? Eclipse supports AspectJ, and shows which pointcuts advise what code.

You say AOP didn't really take off, but I'm pretty sure at least Spring uses annotation based pointcuts in their frameworks.

Anyway, this rant was more about the senior telling me we should only ever use vanilla code because people don't know anything else. If devs aren't willing to learn new things, then they're in the wrong job!

@linux-colonel You can't just simply implement something because you can. There must be justification on why the company should spend additional resource to implement anyone's favorite tool. Sure there are reasons to use other tools the logic here is what tangible benefit is that tool going to bring to the company. The fact is you need to justify your advocacy of the tool of your choice in the angle of productivity. You can't just shove something for no strong reason. Architecture for architecture sake is not a good enough reason to do it. The benefits has to match the labor and time cost that will be imposed on everyone. If you can demonstrate how AOP can make a huge impact in terms of productivity and cost savings, I'm sure it will be very hard to resist. You need to understand there are many other methods and tools other than AOP. investing time and labor in any of them requires a lot of consideration when you are talking about enterprise implementation.

@azzuwan AOP was not the point here, just an example. I've also had problems convincing them to use the jaxb maven plugin at build time instead of checking generated classes into source control. Sounds like you've had a bad experience with AOP, and share my senior's opinion on devs learning new things. If your company doesn't invest in trying out new technologies, then how can your software evolve?

@linux-colonel No man I get you. I don't know if I share the same outlook about technology with your senior.

AOP certainly has it's place just like every other tools,frameworks and libraries. I'm not dissing it. A lot of people like your senior do exist not denying that.

I managing a startup company and also the principal architect. We use range of techs from Object Oriented to functional realm. Java, Go, Python to Elixir and Elm. I'm not averse to learning new tech.

I used to run a Java consulting firm. This was during Java EE heyday circa 2000-2010. We embraced the whole Spring ecosystem after it is clear to us it can reduce our development time and make the maintenance lightweight vs J2EE (EJB2 & the gang). We did this several times with other techs when it make sense to do so. Whatever it is, it must have net benefits, increase the company bottom lines or efficiency and make our lives easier. If you can justify it then no problems. Otherwise it is an exercise in futility.

@linux-colonel Software evolution comes out of real needs and necessity. The whole point of technology evolution is to have something better than the previous technology. What does better mean? Is it just some overly designed architecture that produce exactly the same output as the previous architecture?

The point of evolving to a better technology is so that we can do more with less. We can improve maintainability and increase efficiency. If your implementation brings none of that then it is an exercise in liberal arts like drawing or arch-making purely for aesthetic reason.

So after wasting everyone's time you will end up with nothing marginally better than what you previously have. How is that improvement? And what is the threshold so that another person will not waste everyone's time again with another fancy plan?

it probably make sense if you are in research fields . If you are serving enterprise clients it quite irresponsible to do that.