Sign in to follow this  
Rydinare

Coworker Refuses to Use STL, Boost, Etc.. (C++)

Recommended Posts

Just a general question. If you had a coworker of equal rank (lead) who refused to use standard C++ facilities (STL, Boost, etc...) how would you approach it? His feeling is: A) He owns his portion of the code and can do whatever he wants, regardless of any risk and B) He prefers low-level C and Win32 code in C++ because he wants the people working under him to be extremely aware of underlying pinnings. He's also banned any higher level libraries (COM, MFC, ATL) for his group. I see this as being a large negative for his team and is terrible for teamwork and team building. How would you proceed? I can elevate the issue, but I'd rather resolve things peacefully. Thanks.

Share this post


Link to post
Share on other sites
Tough situation. Are you each in charge of separate teams? If so I'd just focus on using these higher level tools to build better, more stable software faster. Hopefully someone will notice your productivity and you can attribute the difference to your embracing a more modern C++ style.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
I see this as being a large negative for his team and is terrible for teamwork and team building.


How so? I could see saying it has a negative impact on their ability to deliver software but their ability to work as a team seems to be a stretch. Second are you graded on lines of code produced if so he may be ahead in "productivity". What are your design standards? Do they dictate this kind of thing? If he is the team lead for his team then what he says goes for his team more or less.

Personally I would give him anybody on my team who prefers that kind of thing and take anybody from his who doesn't and thank god I don't work for him.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
Just a general question. If you had a coworker of equal rank (lead) who refused to use standard C++ facilities (STL, Boost, etc...) how would you approach it? His feeling is: A) He owns his portion of the code and can do whatever he wants, regardless of any risk and B) He prefers low-level C and Win32 code in C++ because he wants the people working under him to be extremely aware of underlying pinnings.


Don't you have some kind of common coding standards you follow? I mean, either you decide on a team level that you avoid these libraries, in which case he's doing the right thing, or you decide that you use them. And then I'd expect everyone on the team to follow that convention.

If the team, or your project manager, or your bosses or the company or whatever decides on a standard, he'd better follow it. If he refuses to, you don't have many options other than to elevate the issue.

But of course, if you don't have a convention that says "Use proper, modern C++, including Boost", you can't really blame him for not doing it.
You can try to educate him, of course. If I had to guess, I'd say he probably doesn't know C++ well enough to be comfortable with STL/Boost. And if that's the case, helping him learn the language better might be all it takes.

However, regardless of that, I'd say it's a serious problems if he "feels that he owns the code and can do whatever he wants".
Not much of a team player, is he?

Share this post


Link to post
Share on other sites
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.

Finally, I don't blame him for not using it in the past; he probably wasn't aware of the true benefits. Blaming him for not using it going forward once he's made aware of the benefits is going to happen. He's already shown a lot of resistance to even discussing it.

Share this post


Link to post
Share on other sites
Set up a private meeting with him - just the two of you, nobody else. You want a chance to openly and thoroughly, albeit respectfully, discuss his reservations concerning standard and widely accepted libraries without it becoming an "issue." The key is that you don't want to "convince" him to agree with you; you want to hear his reasoning, and then see if there isn't a compromise that can be reached, or if you can't allay his fears.

Most importantly, don't expect him to capitulate fully, no matter how right you may be. It's probably more realistic to aim for a series of gradual changes, where he accepts the uses of, say, <algorithm> first and then, seeing the benefits of that, begins to embrace more standard library elements.

Good luck!

Share this post


Link to post
Share on other sites
Another argument would be that its better to be writing the software you've been tasked with than rewriting what the STL, Boost etc already give you.

Duplicating the efforts of those libraries is probably a waste of time in most situations (there are arguments when rewriting is necessary but it doesn't sound like you're in one of them) and that is time that would be better spent on the project.

Andy

Share this post


Link to post
Share on other sites
Well it depends on the situation but over all if he's just making everybody's life hard for no apparent reason, then clearly remind him that reinventing the wheel won't get him the fame he so hardheadedly wants to earn... how bout reusing the common stuff to reach untouched grounds....

Good Luck!

Share this post


Link to post
Share on other sites
The ego and bad leadership skills aside. When coming into a project that is already established the worst thing you can do is to start "criticizing" the code, decisions, etc... that have already been done and made. It's the past! No sense in dwelling on it. If he's the lead and that is the process he's established then when in Rome do as the Romans do.

Now you can slowly start to turn it around by becoming a advocate for a new process and involving in the whole team. If you can show value in your new process by being a "teacher" rather than a "criticizer" you'll strengthen your position and weaken his. Make sure to try not to devalue any of the work he's done or currently doing, it's default process. Use good neutral words as I feel, I think, We could try, etc... If you don't it'll just breed contempt, put him/her on the defensive, and propagate the negativity. Think "come to the light. Just go to the light man...it's safe, warm, and not bad".

A good leader is a leader who will listen to all their teammates/subordinates and defer to the idea that best fits the given situation. There typically isn't just one smart person on the team. More than often leading is just managing personalities, ideas, schedules, and expectations rather than being the sole individual contributor (ie. best coder, best this, best that) on a project. My current management really suffer from this problem. They = Smart whereas, You = Stupid. It happens...but if you can get them to think they came up with the idea you'll eventually get what you want. Just don't forget to make sure to take some credit while giving your leadership credit.

Anyway...my 2 cents from 4 years of working in a negative, destructive, and generally not very fun environment. I'd leave but the money is too damn good. Though...I have some new job prospects that are equal or greater in pay. Woohoo...

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I would do nothing.

That is his code, he is responsible for maintaining it. Generally people don't use them because they don't understand them. Trying to force him to use something he is unwilling to understand is not helpful.

In your code, use the standard library, Boost libraries, and anything else that will improve your quality. When he eventually works with your code, he will be exposed to it, and perhaps embrace portions of it as he learns to understand what the libraries can do for him.

As a lead, you are in charge of those under you. If they are unwilling to use those libraries, it is your responsibility to find out why they are avoiding it, identify any compromises that should be made, and provide training, mentoring peer review, and other methods to encourage them to use the libraries in the future.

Share this post


Link to post
Share on other sites
As long as he and his group are producing their deliverables on time and at spec, I wouldn't escalate it to higher. In the end, the best way to convince someone to change their programming style is to lead from the front: demonstrate that the code that you and your team produces is simpler, just as fast, more robust and takes less time to create than his style. Try to set a new standard of code quality for your organization. If he and his group can keep up, then maybe you should leave them alone. If they can't, then they'll be much more receptive to suggestions. In the end, actions speak a lot louder than words.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this