Cowboy Programming Game Development and General Hacking by the Old West

January 11, 2007

Delving into Cowboy Programming

Filed under: Cowboy Programming — Mick West @ 2:19 pm

I wrote a bit already on Cowboy Programming, describing it as an individualistic style of programming, the quality of which depends upon the individual. I though I’d do a little research and see what pops up as other definitions of Cowboy Programming (or Cowboy Coding, which is the same thing).

The first result is Wikipedia, which offers this definition:

Cowboy coding is a form of software development method without an actual defined method – team members do whatever they feel is right.

The current Wikipedia article reveals the biases of the authors, but that’s to be expected when discussing a subject that has only colloquial usage. They seem to simply equate “Cowboy Programming” with “bad programming”. Problems are like “Lacks a clear scope and vision”, which is just ridiculous. A good programmer will have a clear picture of the scope and goals of whatever he sets out to do, because he’s experienced, that does not mean he won’t apply cowboy methodology.     Conversely. bad programmers can also have a clear scope and vision, but be unskilled enough to actually do quality work towards that vision.

Moving swiftly on:

However, this has to be a misnomer, because cowboys, and gauchos down here in Argentina, are highly disciplined individuals.

I like that. When did cowboys get this bad rap anyway? In England we refer to “cowboy plumbers”, when discussing plumbers with sloppy work practices and lacking in scruples.

Merriam-Webster says:

Cowboy: one having qualities (as recklessness, aggressiveness, or independence) popularly associated with cowboys : as a : a reckless driver b : a business or businessperson operating in an uncontrolled or unregulated manner.

One Stop English says:

In the US the word still retains its literal meaning but in recent years the word has taken on a new meaning in British English. It is often applied to unqualified workers who promise gullible customers cut-price work and then perform a sub-standard job, particularly in the building industry. If you talk about a cowboy plumber, for example, you are referring to someone who has either done a very bad job for a lot of money or who has left the job unfinished and disappeared with your money. Beware cowboy builders and the cowboy outfits who employ them!

So I’m wondering if the “cowboy programmer” phrase might actually have had some British roots, again from Wikipedia:

In the British Isles, Australia and New Zealand, the term cowboy can be used as an adjective in a derogatory sense. It is usually applied to tradesmen whose work is of shoddy and questionable value, e.g., “a cowboy plumber”. This usage predates the discovery of the New World and originates from the perception that herdsmen are unskilled laborers.

On the European continent the term ‘cowboy’ is sometimes used to someone who behaves as hot-headed and rash as the ‘civilised’ outsiders expect from the ‘savage’ inhabitants of the ‘Wild West’. The term is also used in America. For example, TIME Magazine had a cover article about George W. Bush’s “Cowboy Diplomacy.”

This might account for the confused usage, with the Brits using it as “sloppy”, but Americans more along the lines of “independent” and “reckless”.

More definitions:

… or — the Four Vices of the Programmer
* galloping off on one’s own without a prior plan (the runaway one-liner)
* unnecessarily dense, unreadable code (False Hubris?)
* reinventing the wheel unnecessarily (False Impatience?)
* brute-force programming (False Laziness?)

And a possible contributing cause of bad cowboy practices:

Of course, the students don’t deserve all of the blame, or even most of it. A coding-before-thinking approach to solving programming problems is a rational time- and energy-saving strategy that intelligent students appear to develop early in their careers. This happens in response to the countless toy programming assignments in first- and second-year programming courses, where the approach works quite well. In other words, if the project is small and well defined, if there’s no real possibility of unforeseen interactions between components, and if the consequences of a bug are low (because the edit-compile-test cycle is rapid and because nobody’s actually going to use the software), then why not just jump in and hack, cowboy-style?

So they are saying that programming assignments can actually encourage code-and-fix programing.

Something else interesting:

Worse, when they have access to the test suite used for grading, students who have reached an impasse will often resort to a kind of evolutionary programming where they incrementally tweak parts of a program, test the code, and repeat. This random walk through the program space can move programs away from correctness rather than toward it.

Which seems to almost suggest the Test Driven Development might contribute to bad programming, since the programmer will just bang the code about until it passes the tests, without really understanding it.

Here’s someone pointing at the emperor:

One of the (many) problems with Bad Agile is that they condescendingly lump all non-Agile development practices together into two buckets: Waterfall and Cowboy. Waterfall is known to be bad; I hope we can just take that as an axiom today. But what about so-called Cowboy programming, which the Agileers define as “each member of the team does what he or she thinks is best”?

Is it true that this is the only other development process? And is Cowboy Programming actually bad? They say it as if it’s obviously bad, but they’re not super clear on how or why, other than to assert that it’s, you know, “chaos”.

He goes on to talk about how things are done at Google. Basically “agile” and “well”.

In a response to this:

Agile works, of course, well enough to produce *something*. Any process will work if everyone uses it. But you’ll never know what the code could have been, because the reins are always on the “cowboys”. You’ll just produce competently mediocre code, that never rises to greatness.

Process can hold you back. Part of being a cowboy programmer is having the freedom to ride out there in the wide open spaces, any way you want, as long as the job gets done, and done quickly. Stick a cowboy in a suit, in an office, with rules and procedures, and he’s not going to like it.

Of course, process is there for a reason, not everyone can handle the freedom, and you get “bad cowboys”. But you can have process, and you can have freedom for those that can make use of it. Freedom can actually be a well defined part of your process. It’s called Slack.

Nick Bradbury has a use for Cowboy Programming:

Rather than face that torment, I’ll often start coding away for the sole purpose of running headlong into the cruel wall of experience. FeedDemon’s memetracker is a good example of this, since I’ve already had to start over due to problems that I couldn’t have anticipated.
Here’s the fun part: a week or two from now, after I’m comfortable that the memetracker is working as intended, I’ll then throw the code away and start a more formal design approach. Cowboy coding is a great way to find problems, but it’s no good for commercial software – you’ve got to write well-thought-out code unless you’re willing to be buried in bug reports. So the goal here isn’t to complete a feature quickly (although that’s often a side effect), but instead to discover the gotchas up-front so you can design the feature correctly.

Code and Fix? Nope, it’s code and recode, or code and refactor, or code and rewrite. I’m always re-writing my code (if it’s code that’s going to stay around, or that I’m repurposing). You refactor code when it starts to smell. Perhaps “bad” cowboy programming is cowboy programming without refactoring. Cowboy programming with refactoring is rapid development. You can’t do it right the first time, you can’t design your code and then write it. It’s quicker to code and fix, where the “fix” is appropriate refactoring.

The denigration of “Cowboy Programming” is one of those absurd yet inevitable simplifications that evolve into misunderstood dogma, like “goto considered harmful”, “premature optimization is the root of all evil” and “C++ is slower than C”. “References are better than pointers”. People spout them like they know what they are talking about, when in reality they don’t really understand the nuances of the situation.


  1. I agree with most of your critisim related to critisim and counter-critisim of software development practicies.

    “premature optimization is the root of all evil”
    “C++ is slower than C”.
    “References are better than pointers”.

    It can be said that statements like these were initiated by some experienced programmers. These people knew what they were talking about. But there are those people who read these statements (without relatively less prior experience or insight) and started to believe in them and follow them.

    So lets asssume only 10% of programmers know what they are talking about because of their experience and insignt. The rest 90% are just bouncing off and absorbing these things. Just search google for OO, UML, AgileProgramming and XP etc.

    Comment by ahmed ali — April 6, 2007 @ 2:08 am

  2. […] far in this unit (I’m the only one), I’ve been practicing Cowboy Coding or Hero […]

    Pingback by [ ] » Development Method — February 3, 2009 @ 11:45 pm

  3. I really believe in almost all Agile anecdotes, but, when it comes to Unit Tests, in my field -GUI, I feel the Cowboy programming way has it better.

    I was given the opportunity to “race” the development of three-men who are sworn to agility vs. myself, sworn to deliver. I have finished in 3 weeks. They never did. Unit Testing killed 70 % of their time imho.

    I wish I could post evidence (screenshots of poor results by equally skilled programmers sitting in the same room and same meetings)

    Comment by startxxx — February 9, 2009 @ 7:29 am

  4. I’ve seen people discuss Agile development as a way to undercover problems earlier in the development process, or as a way to reign in the less than stellar employees (who can work with a team vs. who is a ‘cowboy’ looking for all the praise?) If Cowboy programming isn’t working for you, perhaps XP is a way to introduce some quality measures. Or at least pair up a cowboy with a disciplined person.

    We actually use a great tool that gives everyone in the project great visbility into the process, how we all relate, and actually has helped improve morale. Click on my name for it.


    Comment by Mark — March 23, 2009 @ 11:39 am

  5. […] has heard of the COWBOY Programmer, the personality of someone does what they want even though they are working on a team. Sometimes […]

    Pingback by The extreme IT personalities and how to lead around them. « The World of an IT Leader — June 28, 2009 @ 10:05 am

  6. Project philosophy is rarely correlated with end quality, raw hacker talent, IQ and experience always correlate with quality.

    Comment by F — July 23, 2009 @ 7:29 am

  7. Cowboy development definitely has its place, and so does process-driven development.

    One would not want to build a missile guidance system or mission critical application without a high degree of planning, design inspection (2nd or 3rd party), and post-coding review.

    However, applications that are less mission critical or for end-users who do not need defect free software, it’s a great solution.

    For instance, the company I work for makes hospital software. I built a black box application that simulates a hospital’s environment, and it works great for our quality assurance department. I wrote it autonomously, guided more by “gut feeling” about how it should be, rather than going through the traditional SDLC process, and it works great. From time to time, there’s something not quite right that needs to be fixed (I abstain from using the word defect, because I’m not sure there can be a real defect without real requirements, but I digress). When this situation occurs, I fix it, publish to the QA department the updated library or libraries, and they go on their way.

    So, yeah, Cowboy development is appropriate for some things.

    Comment by Tim Claason — August 6, 2009 @ 7:43 am

  8. I agree with Tim Claason as where cowboy coding has its place it certainly does not belong to mission critical applications where it is important that the application works well and is thourougly tested and reviewed.

    Cowboy coding also is not suitable in development teams consisting of more than a couple of developers which may work on the same components because that creates unclear code which is not easily understood and changed.

    However for small, non critical applications written by a single programmer Cowboy coding can be used. Still if the application is to be maintained by another programmer it is good to follow common coding conventions and have automated testing. That is not something that can be left out because the programmer did not feel it was important at the time.

    Comment by Shakor — September 22, 2009 @ 5:33 am

  9. Is any process done badly a bad process?

    Methodologies tend to backload results. Software takes a long time and a lot of money to develop. It’s important to show the people paying that the money they are spending is being used to produce more than reports and reams of documentation.

    Cowboy programming is very good at delivering results early, clients like that. Unfortunately all you’ve managed to do is take a prototype and raise the expectations of the clients into thinking the project is 80% complete because it “looks” 80% complete. This is bad.

    Any methodology, you name it, in my opinion must be results oriented but it can’t backload results. You can’t go a year without showing the stakeholders something tangible. If you try then you are putting immense pressure on the developers to “manage” the clients impatience with the project. The developers are the ones who work all night in an attempt to satisfy the frustrations of the clients in spending all the time and money and having no code to show for it.

    Any methodology, or none at all, must manage client expectations, involve all of the actors all of the time – not dump problems on the developers, and must deliver results progressively so the clients can see something for their money – they need to see continued progress.

    The typical “cowboy” ad-hoc method is subject to the 80/20 rule. You talk to the client and in a short time you return with something which, to the client, looks almost complete. It looks great, just make the buttons do things, make the list and grid show real data, essentially, go back and fill in all the blanks, easy.

    Now you’ve got a situation where the client thinks you’re 80% done. The problem is that they expect you to be finished any day now but you’ve still got weeks or months of work to do to finish. After another week the client asks why you aren’t done yet. They think you’re 80% done because they have seen it with their own eyes. Nothing you say will convince them otherwise. Weeks go by and the client is still look ing at the same almost done view, they see no change and assume you’ve gone to sleep or are being lazy.

    Method is about delivering a product to the client which meets or exceeds their expectations at every stage of development. It’s not about getting it done quicker, in fewer lines of code and with fewer bugs. Whichever one does that for you at the lowest cost is the one you should use and it may not be the same choice every time.

    Building a trader accounting app from scratch requires a different process than throwing up a email response form on a website. You wouldn’t go to a jobsite with a toolbox full of hammers, why would you write software that way?

    I try to use the best tool for the job at hand. There are plenty of methods to choose from. Many of the “examples” above are examples of people who chose the wrong tool for the wrong job, not necessarily some fatal flaw in the methodology.

    Comment by Erik — December 8, 2009 @ 12:47 pm

  10. So refreshing to see another person take the right approach to analyzing Cowboy practices. I think the problem with our image is that people don’t see the inherent limitations to Cowboy: (1) It requires good people, and (2) It doesn’t scale.

    As long as you have a small team of good people, it can be the greatest choice of all. Especially if you plan to go iterative (in one way or another).

    What? You can do Iterative Cowboy. Works great in my shop.

    Comment by Kevin C — March 14, 2010 @ 12:12 am

  11. Works best with a single programmer. I’m doing some cowboy programming right now. Fast moving stuff, but not suitable for team work. Can be massaged into shape though.

    Comment by Mick West — March 14, 2010 @ 12:15 am

  12. […] “hygiene” ”“ หมดยุคของ Cowboys Coding ([1]/[2]) แล้ว ได้เวลาศึกษา bug tracking systems, version control […]

    Pingback by 10 ทักษะที่ Developer ควรรู้ | — July 31, 2010 @ 9:56 pm

  13. […] This post was mentioned on Twitter by Mario Vilas, Mario Vilas. Mario Vilas said: I think this comment really nailed it […]

    Pingback by Tweets that mention Cowboy Programming » Delving into Cowboy Programming -- — January 26, 2011 @ 4:54 am

  14. […] Cowboy coding – Wikipedia, the free encyclopedia. see, too. Share and […]

    Pingback by Cowboy coding | Jesus Was Rasta — July 7, 2011 @ 10:17 am

RSS feed for comments on this post. TrackBack URL

Leave a comment

You must be logged in to post a comment.

Powered by WordPress