Cowboy Coder -- a software developer who may develop software quickly, but who has problems working in a team and following disciplined processes for design, testing, and documentation.
"Cowboy coder" is a derogatory term in the software engineering community, because there is a perception that they build products that are difficult to extend and evolve. Even so, there are many small companies where cowboy coders are valued for their skills at producing software product code very quickly. Many small startup companies rely on a small group of expert programmers to build initial versions of their products. Quickly-written code is often brittle -- the code can be hard to test, and most attempts to add new features to the software will create some subtle bugs. If a product is successful, a company may need to rebuild large sections of their product with a more balanced team of developers and a more carefully planned code structure.
Cowboy coders can be very useful in the development of new products in business domains where are product quality and reliability are less important -- and where the lifetime of the software is relatively short (a year or less). Financial trading software, short-lived web applications, and many cell phone apps fit into these categories.
On the other hand, most software products in our industry require a high level of reliability, and the lifetime of most commercial software applications is at least 5 to 10 years. Long-lived products will be enhanced and extended by developers who were not necessarily part of the original product team. The work of cowboy coders becomes a liability -- the fact that a software product is a team effort puts a premium on code clarity, good design structure, adequate design documentation, and good quality software tests. Most cowboy coders have little patience with following coding standards, sharing information about the software design with others, and applying development approaches that improve testability.
Are cowboy coders a problem for creating good quality software products? Here is what Steve McConnell has to say in his book Professional Software Development (p. 73):
Unfortunately, the reality is that for every programming hero who is capable of monumental coding achievements, there are other pathological programming disasters who just don't know how to work well with others. They hoard design information and source code. They refuse to participate in technical reviews. They refuse to follow standards established by the team. The sum total of their actions is to prevent other team members from making potentially valuable contributions. A significant number of programming heroes don't turn out to be heroes at all; they turn out to be prima donna programming ball hogs.
Individual heroics can contribute to project success, but teamwork generally contributes more than individual accomplishment does. A study at IBM found that the average programmer spends only about 30 percent of the time working alone. The rest is spent working with teammates, with customers, and on other interactive activities. Another study of 31 software projects found that the greatest single contributor to overall productivity was team cohesiveness.
In my experience in AT&T, Lucent, and Alcatel-Lucent, the projects that had the most problems with cowboy coders were the projects that had development teams with less than 5% female staff members, and the best projects and teams had 40-50% female staff members. There are probably some complex sociological reasons for this, but I think that there are two main explanations:
Female developers are more likely to be more global thinkers and they are more accustomed to working in a diverse team, and their values can rub off on other team members.
I have been thinking about the last couple of paragraphs of the preceding article -- and I have a few extra points to make:
There has been some recent discussion about "political correctness" among some members of the software developer community -- criticism that companies that have used "diversity goals" as a justification for hiring software developers with lesser coding skills.
In my opinion, these criticisms are off base. I can think of four reasons to defend a company that chooses to include diversity as a key factor in their hiring process: