I was driving down the road to pick up dinner when a familiar tune came on the radio. I usually listen to music on my Windows Phone, but I had forgotten to put it in my pocket before I left. The song started out with an electronic voice saying “cowboy… cowboy.” Since I grew up in the 90s, I decided to turn it up for nostalgic purposes.
Back in the 90s, I was a certified cowboy coder. Even in 2000 when I started working on a team project, the team and the product had little to no discipline. Requirements were handed off as features the owner of the company would like, and they were divided up to be tackled by individuals based on interest. Some might call this “agile,” but there were no cycles, no unit testing, little shared ownership, and little accountability. I did things my own way, and learned from others around me.
As I matured as a developer, I came to realize how important certain skills were in working with teams. I found myself worrying about the maintainability of code as I knew it would one day be handed off to others. I found myself wanting to ensure my code does what I expected it to do. I found myself caring less about what I was doing specifically and more about the success of the team.
Earlier today, I encountered a StackOverflow question about what the opposite of TDD. Someone proposed the term “Cowboy Driven Development.” I feel this term isn’t correct, because an individual cowboy coder may utilize test-driven development. The response also contained a list entitled “The Cowboy Way.”
The Evil Cowboy Coder

The list the user posted describes someone you would despise working with. I followed the provided links to the source on c2.com. The top paragraph of the wiki describes the traditional cowboy coder, but the list describes someone I can only deem as an evil cowboy coder.
The Cowboy Way (from c2.com):
- The speed with which I can hack something together determines my worth
- People who need comments in order to understand my code are too dumb to be working with me
- People who ask me questions about my code are too dumb to understand it, and (therefore) are too dumb to be working with me
- Other people's code is just crappy, but mine is self-descriptive and beautiful
- Exploiting a compiler-dependent language feature to save a line of code is "elegant"
- Other people on my team cause all of the bugs; I'm the one that fixes them
- My code is never at fault, always perfect, and I don't make mistakes
- Since my code is never at fault, I don't need to test it thoroughly, if at all
- Since my code is always perfect, it never needs to be refactored no matter how long it's been in the codebase or how much has changed around it
- Since I never make mistakes, I can yell at anyone else who does
- Since my code is perfect, if the program crashes due to unexpected data, it's the user's fault for entering bad data.
- Since my code is perfect, if the program fails after a minor machine configuration change, it's the sysadmins fault for changing it.
- Since my code is perfect, if the program runs too slowly, it's the managements fault for not providing a faster machine.
If someone exhibited all of these traits, I am amazed they have a job. However, I don’t really think this is a traditional cowboy coder than a know-it-all or alpha coder. These developer archetypes aren’t mutually exclusive.
Here is a contradictory quote immediately following the list.
I worked in a whole company of these people; some of whom really seem to think this way. They're nice people, don't get me wrong, but they just don't seem to think very much about the usability of their code.
The list describes someone who is downright mean. Sure, the subject may be nice on other topics, but when it comes to code, this person is horrible.
I don’t think c2.com list is a good indicator of the evil cowboy coder, or the code rustler. Here is a better one.
The Code Rustler Way:
- Making money is of paramount importance; therefore I will obfuscate code and withhold vital information so I will need to be consulted in the future.
- I ignore standards set by team.
- I intentionally use poor naming so others cannot understand it.
- I become irate when others modify my code.
- Since I pasted the code, it’s mine to take credit for even if copied off the Internet.
- I steal code created by others from one project and use it on another.
The Good Cowboy Coder

The cowboy coder who is not a code rustler may not work well in teams, but this person is good, and even desired, for certain situations. Here is how to identify a cowboy coder.
The Cowboy Way:
- The speed with which I can hack something together determines my worth.
- Team standards do not matter to me, only working code.
- My own tools and processes are proven, therefore I will use them.
- I am not concerned with what others think of my coding style.
Startups and small business will bring a cowboy coder in to quickly create projects. The result is that other developers have difficulty in maintaining the project as the code, processes, and tools may not be familiar. However, the business requirements may dictate a need for speed and lower cost to quickly get the project off the ground.
Other companies may bring in cowboy coders to troubleshoot issues with a current codebase. This occurs when the development team is already having issues meeting deadlines, and bugs are piling up. The contractor doesn’t have time to become familiar with the processes of the team and is brought in only to alleviate existing problems.
Cowboy coders are regularly hired to do small projects for companies without project management or a development team. When that coder moves on, another cowboy coder is brought in to make enhancements or bug fixes. I’ve worked on projects with many styles of development, and it was likely a result of several cycles of cowboy coders.
You’re Not Immune to Cowboy Syndrome
You work well in a team that practices SCRUM, BDD, and you prefer declarative code. One day, you find yourself put on a team that uses a different set of standards and practices. SCRUM and BDD have worked well for you, do you try to change the team or do you acclimate?
You have several options: adopt the team’s standards, encourage the adoption of your standards, go rogue, or find another team. A few years ago, I worked on an Agile/SCRUM team that had a cowboy coder. At first, he tried to change things to his “better” way. When it was rejected, he continued doing things his way. He was moved to a position that would have minimal impact on the rest of the team, but eventually he became fed up with it and moved on.
Now consider this: are you agile? Would you do the same as my former coworker if you were on a team that wasn’t agile? If so, you would be deemed a cowboy coder as he was.