Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I found a question (code cowboy on the team), but it was more related to "Ninja Coder" then the problem that I have.

I have a team member who is a pure living example of "Cowboy Coder". I do understand that one can't change people, but is a way to make him stop behaving like a "Cowboy Coder"?

He refuses to listen to the team, and he recently stopped code reviews, unit testing, sharing the implementation details, etc.

Yes, he "codes" fast, but his code is just a bug generator. Other team members and I are in a "bug fixing phase" and 80% of bugs comes from his code. I don't want to fix his bugs. And management is blind, or doesn't want to see this, or maybe they like his "speed".

Is there any way that I (as his younger colleague by age, not his boss) can do something about it?

How can I disarm this cowboy coder?

I feel like I'm the last one who really cares about the project at all.

share|improve this question

closed as off topic by gnat, JeffO, BЈовић, GrandmasterB, Walter Jul 18 '12 at 20:15

Questions on Programmers Stack Exchange are expected to relate to software development within the scope defined by the community. Consider editing the question or leaving comments for improvement if you believe the question can be reworded to fit within the scope. Read more about reopening questions here.If this question can be reworded to fit the rules in the help center, please edit the question.

2  
Where I work the bug rate does get noticed. It is weird that management does not see that as a problem. Ideally, you would be fixing your own bugs and he would be fixing his - that way one can measure the true speed at which he codes and you code. –  Job Jul 18 '12 at 15:30
17  
This guy needs to fix his own bugs. Why isn't every developer required to go through code reviews? –  Jason Holland Jul 18 '12 at 15:31
8  
Under who's authority did he stop code reviews? –  Otávio Décio Jul 18 '12 at 16:06
13  
So... you got not one managing this thing. That's your problem, not the cowboy coder. –  Otávio Décio Jul 18 '12 at 16:12
6  
But how do we disarm "close thread" cowboys... –  Rig Jul 18 '12 at 21:44

5 Answers 5

I see a few options:

  • Approach the coder with your concerns. It must be done as constructive criticism with specific points. Before taking bigger steps it's appropriate to raise concerns directly and in private to give the person the opportunity to change.
  • Gather information and statistics and bring it to management. Management might not appear to care, but it's often important to make the effort anyway in case it works. Possible negative consequences include alienating others who don't appreciate complaints to management.
  • Find a peer of the cowboy coder and discuss it in private. He/she might have a better chance at getting the person to listen.
  • Ask to work on another team. Won't solve the problem but you'll keep your sanity. At the very least always work to the best of your ability and don't let it drag you down.
  • Leave the organization if no one will listen. It sounds like a bad environment.
share|improve this answer

Go to management with your statistics about how many bugs/issues are coming from this one developer. Explain to them that fixing their bugs affects your team's productivity. If indeed 80% of issues are coming from one person, that definitely needs to be addressed. As long as you explain it to management in terms they can agree with (i.e. "time wasted is money wasted"), they will intervene.

Also, this developer should be fixing their own bugs/issues, so it may be helpful to assign these issues to them. Your team should not be covering for this one person.

share|improve this answer

Is there any way that I (as his younger colleague by age, not his boss) can do something about it?

Peer pressure and leading by example are the only good ways. The best ways are done by their boss/lead. If you're not their boss/lead then talk with those who are. But in the end it's their job to take care of it, not yours. Make sure you're doing a good job and things tend to work themselves out.

share|improve this answer
1  
The cowboy coder might be immune from pressure, if management doesn't understand his true impact they might be blinded by his perceived impact. –  mhoran_psprep Jul 18 '12 at 15:51
    
He can advocate his mistakes very well before management, so that large bugs or issues look small to management, but at the end, the code remains ruined. And that's something the management don't care. –  Adronius Jul 18 '12 at 16:04
2  
@mhoran_psprep - Oh certainly. I don't expect him to be successful, but I also think that trying to fix things otherwise are more risky with regards to having negative consequences. Making a giant fuss about it is a quick and easy way to get yourself ostracized, especially if the OP's perceptions of the cowboy are inaccurate. –  Telastyn Jul 18 '12 at 16:08

He refuses to listen to the team, and he recently stopped code reviews, unit testing, sharing the implementation details...

Code reviews don't necessarily require the coder to submit the work for review.

An easy way to keep track of what he does is to keep an eye on the VCS history, looking for his check-ins. If you're worried about his code, this is an easy way to find it. Get a diff history, look at what he put in, and see if any red flags jump out at you. Catch his checkins fast enough and if you find a problem, you can roll back the commit and e-mail him to that effect. You are allowed to call out your fellow team members, even as a junior coder, when you see something obviously wrong.

Yes, he "codes" fast, but his code is just a bug generator. Other team members and I are in a "bug fixing phase" and 80% of bugs comes from his code. I don't want to fix his bugs. And management is blind, or doesn't want to see this, or maybe they like his "speed".

Code comes from requirements. Requirements result in runnable tests that verify the requirements have been met. Those tests can be further broken down, and can be written before changes are made to verify that the changes meet the requirements (red-green-refactor; the essence of TDD).

Add a "code coverage" metric to your team's build server (hopefully you have one; if not, that's your first problem). Simply checking that unit tests pass won't catch the problems with his new non-TDDed code, made in areas that don't have unit tests. After running all unit tests, the build server should ideally have executed every line of code, but there really are some things you just can't unit-test. Realistically, you should still be able to expect 95% coverage or better (or exclude certain libraries or types of files from coverage). Sooner or later, your cowboy will check in something that breaks the build because he's dropped the coverage level below the threshold, and you call him out.

And as far as "speed" is concerned, speed is how fast you get things "done", and it's not "done" until it's done correctly. You can put it to your managers this way; consider an auto mechanic who, when the manager takes his BMW to get an oil change, forgets to out the oil pan plug back in, and as a result all the new oil pours out before he even drives out of the garage. Sure, the oil change only took five minutes, but the manager's not going to care about that when his car's engine seizes up on the way home. He's going to care that the mechanic missed a step, that is going to cost him a lot of additional time and money to have fixed. Right now, he's paying one cowboy to do the job really fast, and then he's paying the rest of the team a much larger sum to come in and re-do the job correctly. What, really, is the advantage of continuing to let the cowboy do his thing?

Is there any way that I (as his younger colleague by age, not his boss) can do something about it?

Call him out. When you find something he screwed up, show him how his code is failing, how he could have prevented the problem in the first place (including proper design, TDD, code reviews) and what you were or will be required to do as a result to fix his broken code.

I feel like I'm the last one who really cares about the project at all.

klaxons blaring, lights flashing, sirens wailing - if you really do feel like you're the only person who cares about the quality of code produced by the team, then there is a SERIOUS problem. If you feel you're trying to drag the entire team kicking and screaming into the era of good coding, and it's just too much weight to haul, then drop it. If there's another team at the company that's doing it right, ask for a transfer, otherwise get the hell out.

share|improve this answer

He refuses to listen to the team, and he recently stopped code reviews, unit testing, sharing the implementation details...

Do you not have a documented path for code through review, testing and implementation? If not, you've a wider problem. If you do, then this is something that needs to be escalated.

share|improve this answer
    
Sure, we got tons of processes and documents. But it is about people how they use them. –  Adronius Jul 18 '12 at 16:27
    
But nothing should get onto production without acquiring relevant sign off. Are you telling me he circumvents normal change control? –  temptar Jul 18 '12 at 16:31
    
Not exactly, but kind of. He makes changes to the code, then he do the "formal" steps to do the code review = uses some tool by himself only, so the code has "reviewed" flag or ask his mate (that doesn't care about code) to "review" his code. Then he "explains" the code in a minute and it's done. Huray, and he goes to submit the changes. –  Adronius Jul 18 '12 at 16:45

Not the answer you're looking for? Browse other questions tagged or ask your own question.