How to deal with inept management

Question

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.

Answer 1

I'd recommend approaching your concerns as 'suggestions'. Make a suggestion and ask for their opinion on it, that way they feel as if they are still in control even though you've planted the seed and are directing the conversation.

Regardless of how long you have been with an organization, you are there and you are there for a reason (they hired you for your input). Find your voice and how to best approach your team members with suggestions and/or concerns. This is a crucial part of being a team member and will increase your value.

Answer 2

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).

Answer 3

Get a good formatter and create you method names this which they cannot complain about then your discussion can move onto real issues.

Some people cannot get over these little details during reviews, so you need to make it a non-issue.

Answer 4

I disagree with the recommendation of another logging framework besides log4j. Citing an old review, without any kind of personal experience, should not win the day here.

However, there might be a way to turn this to your advantage. If you agree and recommend the logging built into the JDK or Apache Commons logging, you'll find that both are quite similar and can actually use log4j as their underlying implementation.

If your adversary isn't paying much attention, you may win points for giving in and avoiding a bike shed argument and STILL get what you want.

Answer 5

My guest, you are wrong. Wrong from the beginning.

My guest again : do not hesitate to ACCEPT conter reactions !

It may have you pass that rank : rookie.

Note : Management are our employers. They pay us as long as we can help them. If they don't want you, you're wrong -- and they are right since we talk about there money. If your right only in your book, you have a problem...

Answer 6

Your work has to gain credibility before they will listen to you. So yes, do as others have recommended, and make sure the unimportant formatting laws are adhered to. But also do such high quality work that they can't ignore or marginalize you. Try to guide them in ways that makes them think the ideas are coming from them.

Answer 7

You guys were right..seems to have been the correct approach

Answer 8

Respect your elders I say! :)

Really though, just remember that a lot of these gray beards were probably programming while you were in diapers. That doesn't make them experts in the latest technologies, but it should at least earn your respect. And sometimes if you can find a way to look past all the hemming and hawing and "back in my day" stuff, you can pick up some pearls of wisdom from those old dogs!

Now from the programming perspective, looks like Yishai has it right. It should be pretty easy to conform to the coding styles they want, and once you've made them happy you can run with the code the way you want.

And if you have to present a counter opinion, back it up. If you want to use something like log4j, talk about SPECIFIC projects in your past where you've used it and it worked fine, and offer to help anyone get past any problems they have with it, etc. etc.

Remember, while you look at the old gray beards as not knowing how to do some cool new programming, they probably see you as a young whipper snappers with a lot of crazy ideas out to change the world. An ounce of patience will get you a pound of respect.

Answer 9

I am an old gray beard but I abandonded COBOL 35 years ago and code in dotNET C# and have kept up with the young wippersnappers and try to mentor them too. With that said I see a lot of managers and programmers that are still in the dark ages like VB6 and cannot accept web farms, web services some of these gray beards and young wippersnappers cannot normalize a database table to 3NF let alone code nTier, WCF or have a clue. Worse yet some of the managers are 30 years behind and rely on the VB6 at best and a flat file using Access97.