When I was growing up, going to the movies on a Saturday morning usually meant a cowboy show. But cowboys on the big screen -- those tough, individualistic, lonesome heroes of the Western plains -- were a lot more useful (and entertaining) than cowboy programmers are on your development project. How do you know if you have a cowboy (or cowgirl) programmer on your project? The following list should give you a good idea:

A cowboy programmer:

	Has the definitive answer to any development question on a moment's notice.
	Has a different definitive answer in an hour (or day).
	Implements changes at will, without prior discussion with those whose work the decision will affect.
	Automatically assumes that any bugs are in someone else's code.
	"The answer is threading, now what' the question?"  is a standard response (substitute any number of keywords for "threading").
	Thinks analysis/design is for wimp -- Nike mode is best ("Just do it").
	Is not only an expert in a limited knowledge domain, but in ALL knowledge domains.
	Thinks whatever answers others come up with are wrong.
	Thinks throwing code "over the wall" is a valid development technique. Testing is for wimps.
	Never, under any circumstances, says, "I don't know."

Cowboy programmers are a dirty little secret of many failed development projects, but in all the cases I've seen, the cowboy programmer is NOT the core issue -- the problem is management. Because cowboys can, without reservation, promise management the impossible on a daily basis, managers/project leaders follow their advice over more realistic (but less satisfying) advice from others on the project. Numerous studies have indicated that the most consistent and intense complaint from team members is that their team leaders were unwilling to confront and resolve problems with uncooperative/unproductive team members.

So what can you do if you find yourself on a project with a cowboy? There are several possibilities:

	Peer pressure: For mild cases of the affliction, having a good heart-to-heart talk with the cowboy (maybe over a long lunch) might be effective. Some people are cowboys because they just don't know any better.
	Talk to the project leader/manager as an individual about the problem. If the manager/project leader doesn't have his/her head buried in the sand, they may accept that there is a problem and counsel that person with the facts of programming life. At the risk of being repetitious, cowboys are a management problem, and must be taken care of on that level. Hey, it could work!
	Talk to the project leader/manager as a group (can be effective if the group is a large percent of the project team). If the manager is more of an ostrich-type, they may ignore one person's complaint, or even complaints from multiple people one at a time. But it is very hard for any manager to reject the massed complaints of a large subset of the group's programmers. Unfortunately, by the time it reaches this stage, the dialog is usually some variation of "Get rid of Jim or we're all quitting."
	Consign yourself to fighting a range war for the whole project. For a short project, this might even be viable, although frustrating. But for a mid-size to large project, the accumulated frustrations are so destructive that I can't really recommend the method.
	Move to another project within the company. Depending upon internal corporate policies, this might or might not be possible. It doesn't solve the core management problem, but it gets you out of the gunfight.
	Move to another project for another company. Unfortunately, this is the most common scenario. Why a company would spend thousands recruiting developers, and more thousands on further training (both OTJ and external), then lose the developer because they will not resolve people problems is a constant source of amazement to me, but it happens all the time.

Cowboy programmers, with implicit or explicit management support, are one of the most dangerous risks for any project. Even if they are kept from unduly damaging the integrity of the system, the cost in frustration and demoralization to the rest of the project team is never worth whatever value the cowboy otherwise brings to the table.