Cowboy Programming Game Development and General Hacking by the Old West

(This is just a programming anecdote.   If you want to know how to program something that plays scrabble, then look here: http://www.gtoal.com/wordgames/scrabble.html)

A couple of years ago I was trapped in Truckee, California, snowed in somewhere up a mountain in a little cottage, with no electricity. It was the holidays, and I was visiting with the in-laws, and we’d just had a rather unsatisfying game of Scrabble. Unsatisfying because we had no dictionary, and so no way to validate challenges, which makes the game even less visceral than normal.

So my laptop still had a few hours of juice left, so I resolved to write a quick scrabble word checker. As it happened I already had the list of valid scrabble words(ospd.txt), which can be downloaded from http://web.mit.edu/rwbarton/Public/ospd.txt

At first I though a quick batch file would do the trick, but after a few minutes poking I got annoyed, and decided to simply brute force it, and write it in plain old C++, just to pass the time. Half an hour later I came up with this monster (stripped slightly):

		w = (char*)argv[1];

		char * p = new char[10000000];		// 10MB
		FILE * x = fopen ("C:\\ospd.txt","rb");
		for (int i=0;i<10000000;i++)
			p[i] = 0;
		fread (p,1,10000000,x);

		int len= 0;
		while (w[len])
		{
			if (w[len] >= 'A' && w[len] <= 'Z')
				w[len] -= ('A'-'a');
			len++;
		}

		char *s = &p[0];		// w = search pointer to start of word

		int valid = 0;
		while (*s != 0)
		{
			int letter = 0;
			while (letter < len)
			{
				if (s[letter] != w[letter])
					break;
				letter++;
			}
			if (letter == len && (s[letter]==0x0a || s[letter] == 0x00))
			{
				printf ("%s is GOOD\n",w);
				valid = 1;
			}
			while (*s != 0 && *s != 0x0a)
				s++;
			if (*s == 0x0a)
				s++;
		}
		if (valid == 0)
			printf("%s is BAD\n",w);

Now there’s some hackery, quite embarrassing really. It’s a good example of Cowboy Programming because:
– It’s long and messy code
– It’s using an ad hoc solution to something that has been solved many times before

But the key thing is that it works. It’s a perfect solution to the given problem in the sense that it solves the problem perfectly. But it’s nothing beyond that.

Of course, you can do the same thing in one line of Ruby:

puts IO.readlines("ospd.txt").include?(ARGV[0]+"\n")

But I did not have Ruby (or Perl) installed, and since I’m no Ruby expert, and had no Internet access, that one line of Ruby could have taken me longer to write than the 50 lines of C++.

However, had I persevered a little, I could have figured out the batch file:

@echo off
for /F %%f in (ospd.txt) DO if "%%f"=="%1" @echo %%f IS GOOD!

In hindsight, what should I have done, wanting to be a “good” cowboy programmer? Well, my goal was to solve the problem as quickly as possible, and I knew the code was never going to be looked at or used again. I knew that very simple solutions existed, but I did not know how to get to them. I knew I could get to those simple solutions eventually, but I did not know how long it would take. On the other hand, I knew if I programmed in C++, the code would be long and messy, but I knew exactly how I would write it, and I knew roughly how long it would take, about 20 minutes.

So, the choice was a short and elegant solution in between two minutes and two days (if I had to wait until we escaped the snow), or a long and messy solution in twenty minutes. Take the money, or open the box? I experimented briefly, and then chose the known quantity. The messy code was written. Done.

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:
http://en.wikipedia.org/wiki/Cowboy_coding

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:
http://wiki.awebfactory.com.ar/awebfactory/published/CowboyProgramming

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:
http://www.onestopenglish.com/section.asp?theme=mag&catid=59783&docid=154457

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:
http://en.wikipedia.org/wiki/Cowboy

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:
http://www.coder.com/daniel/style-large-yapc/slide007.html

… 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:
http://dsonline.computer.org

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:
http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html

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.