Coworker Refuses to Use STL, Boost, Etc.. (C++)
If you were developing safety-critical software, his position might make more sense. At my previous job involving safety-critical software the mentality was that nearly all code must be developed in-house, but exceptions were made if a rigorous review of outside code could be performed in a reasonable amount of time. I think I would've gotten laughed at if I asked to bring boost in through the iron gates.
I would beat him with a stick until he got with the program.
Lighting him on fire is also persuasive. Verbal sticks are more PC, but less effective.
Being a little more serious though, I would do nothing. I'd make the argument that it's dumb business and bad engineering. (I presume you've already done that). If that seems not to help, I'd make the argument casually to your (shared?) boss that it's dumb business and bad engineering. Imply that you're not going to touch anything that the other team deals with. If the other lead wants to do his stuff his way, then he takes the consequences. And then I'd leave it be.
Realistically it is dumb business and bad engineering. The effects of such will bring themselves to bear eventually, and take the policies and supporters down with them.
Lighting him on fire is also persuasive. Verbal sticks are more PC, but less effective.
Being a little more serious though, I would do nothing. I'd make the argument that it's dumb business and bad engineering. (I presume you've already done that). If that seems not to help, I'd make the argument casually to your (shared?) boss that it's dumb business and bad engineering. Imply that you're not going to touch anything that the other team deals with. If the other lead wants to do his stuff his way, then he takes the consequences. And then I'd leave it be.
Realistically it is dumb business and bad engineering. The effects of such will bring themselves to bear eventually, and take the policies and supporters down with them.
If its not your team then its really not your problem. And if it doesn't impact your work in any way keep out of it. Without knowing the complete situation how can you know that your way of doing things is best? Maybe the company wants to "own" everything code wise that goes into the product. Not that it would ever happen but what if STL or boost went to a GPL license? It would pretty much screw a whole industry over. Maybe they are willing to reinvent the wheel so they will never deal with something like that. Then again he might be one of those guys who thinks he has to know how every little piece works by creating every little bit himself.
Well, have you asked him the reasoning for the methodologies he is using.
In my company we just can't use boost because of a lot of issues and until it becomes a C++ standard and supported by all compilers we have to just avoid it.
Trust me on this though - everyone is resistant to changes. You will have to do incremental changes( very small small ones ) so it doesn't hurt the persons ego and you get what you want as well. Just make sure it doesn't become a ego clash.
In my company we just can't use boost because of a lot of issues and until it becomes a C++ standard and supported by all compilers we have to just avoid it.
Trust me on this though - everyone is resistant to changes. You will have to do incremental changes( very small small ones ) so it doesn't hurt the persons ego and you get what you want as well. Just make sure it doesn't become a ego clash.
Quote:Original post by Rydinare
Some background behind it is that I'm new to the team. We're working on the same project, however, he has a small group on the project that he's been leading and will continue to lead. Neither one of us can overrule the other, was how it has been phrased to me. There's definitely been some feeling that his teamwork is poor. Upon joining the team, I was told that I need to be very involved in reviewing the processes and standards being used -- there are a few small documents, which are pretty minimal. If I elevate it, I'm sure I will have management support behind me, but I'm worried about creating a negative situation.
Ah so You have been given his job while he still occupies it. No wonder he is antagonistic. I would go along on any established product, it can get icky when you try and toss boost and the stl in with straight C code. I would also try to push best practices on new development.
It's quite one thing to reinvent the wheel and develop an alternative to Boost/STL at the beginning of a project, and another to choose to continue to use the team's existing libraries instead of switching to Boost/STL. There had better be some good reason for the former, while the latter is more common and arguably justified.
I agree with most of the posts in that you shouldn't make waves and end up butting heads over this. If you want to support your assertion that the entire organization should standardize on Boost/STL then track the bugs during the course of the project and note which would have never occurred had the developers used Boost/STL instead. At the end of the project, present this data to the project lead and let them decide whether this is worth changing.
In my 20+ years as a software engineer I've seen similar battles over silly things like the placement of braces or whether TABs should be in comment blocks. In the end, all it does it get people pissed at each other and no matter who wins it affects future team interaction in a negative way. Don't sweat the small stuff.
I agree with most of the posts in that you shouldn't make waves and end up butting heads over this. If you want to support your assertion that the entire organization should standardize on Boost/STL then track the bugs during the course of the project and note which would have never occurred had the developers used Boost/STL instead. At the end of the project, present this data to the project lead and let them decide whether this is worth changing.
In my 20+ years as a software engineer I've seen similar battles over silly things like the placement of braces or whether TABs should be in comment blocks. In the end, all it does it get people pissed at each other and no matter who wins it affects future team interaction in a negative way. Don't sweat the small stuff.
choose the moment - take the guy out for drinks - ie make it an informal thing between the two of you and then knife the guy in the back. seriously before he does it to you - and make sure to choose a big knife.
we use c++, and i am the most delicate and cautious advocate of stl (not boost), and confine myself only to the most casual offhand remarks about the possible benefits - if the guy even senses an ounce of frustration or disrespect on your part, or senses you are an indirect threat to his social standing or job security - you risk having to work with someone who will undermine you behind your back at every opportunity.
Sleep( 1000); // avoid race condition
seen everywhere in the middle of a multithreaded teleco app - beautiful in'nt it.
we use c++, and i am the most delicate and cautious advocate of stl (not boost), and confine myself only to the most casual offhand remarks about the possible benefits - if the guy even senses an ounce of frustration or disrespect on your part, or senses you are an indirect threat to his social standing or job security - you risk having to work with someone who will undermine you behind your back at every opportunity.
Sleep( 1000); // avoid race condition
seen everywhere in the middle of a multithreaded teleco app - beautiful in'nt it.
I had a boss who didn't allow STL (or templates at all), because he dealt with lots of new devs who were still students and wouldn't stay long, and he felt that STL hurt productivity... long, illegible error messages and that sort of thing. It's one of those situations where the learning curve made it a cost-prohibitive when dealing with relatively short-term employees.
Also, dependencies on 3rd party libraries are almost always a good thing to avoid if you can. There are always trade-offs. You have to weight the cost in development time versus the cost in dependency management.
Also, dependencies on 3rd party libraries are almost always a good thing to avoid if you can. There are always trade-offs. You have to weight the cost in development time versus the cost in dependency management.
If you're not making a game, and you're writing solely for Win32 anyway (are you?), then I see no reason not to use the best available technologies... but only if the other people on the team already know how to use them!
Id say it depends how far along you are. Is the team being built? or is it already built? If everything is running fine and the existing staff is use to this, leave it alone. Youre gonna be the new guy trying to stir things up, unless all this just started, in which case, kill it now. Its better one learn then everyone relearn. Think about a clean break next time.
Although I cant say after building some GUI libs that I havent thought about C and Win32... or suicide.
Although I cant say after building some GUI libs that I havent thought about C and Win32... or suicide.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
