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.

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.

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.

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.

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.