A project I was working on has finished, so I’ve been moved on to some new tasking at my employer. The previous work was very agile, small team, progress over procedure, etc etc.
So anyway, the new project I’m on – I find myself confused on how to deal with management. They have no real understanding of object oriented programing , current technologies or methodologies. They seem to fear change and just recently we moved to the latest JRE
We do these code reviews and I have to listen to “gray beards” saying how much better it is in ADA or how they used to do things in C. But then when they try to code review – they lack even the most basic understanding of OOP design and dev. They focus more on the style of the code; spacing; method names; etc.
One of the senior level people say we should be writing our own logger instead of using log4j because of one negative review of log4j in an academic PDF written ages ago.
How do I deal with this? How can I explain to them that their design is faulty or that they are really behind the times, without coming across as a jerk. I’ve only been with this organization for about a year – so I don’t know how much credibility I will have.
Regarding the code review, I would say make them happy. Name and space things the way they like. Focus your time on better design, of course, and enjoy the ADA reminiscing, it still can give you some background of where things are today and how they got there.
In other words, don’t take that part too seriously. Worry about what is important to getting the job done. The job in this case is making those that matter feel you made a positive contribution to the project.
Regarding Log4j, I would just suggest a different framework. Either the built in JDK logging (can’t complain about that, it is a built in API) or something like SLF, which lets you plug in whatever you want (including your own, I guess, which you can then throw away and replace with something real when they realize it was a mistake, and you only have to change the classpath).
Now there will be times where it is important. In that case, make it sound as much as possible that it is their idea. For example, on the logging, state that there are many logging frameworks out there that represent a lot of lines of code, and you were wondering if there are other ways to leverage that work for this project, and then let them “figure out” the solution.
There will be times when you have to push something as your idea – there will be no other way. In that case stick to the evidence, martial allies as much as possible by keeping relationships with those that do have influence in good standing, and realize that every battle you fight, you lose position, even if you win (perhaps especially if you win).