Cowboy Coding

CowboyCoding is a DevelopmentStance.

As such, it's a reference to a mythical American west rather than the actual tasks involved in being a cowboy. CowboyCoding is shooting from the hip, with NoProcess. Its key aspects are:

An emphasis on ingenious artistry as opposed to plodding team-play. Since what makes software have the QualityWithoutaName is little understood, the cowboy approach often reaches new heights through the artistry of the practitioner. The results, however, are often spotty and rarely easy to duplicate.
A nearly complete absence of advance planning. Cowboy coders code in the moment, with little affection for considerations of the future or even the past. However, there is a branch of the cowboy discipline that thrives on the blue-sky possibilities of software, discussing what is going to be done until the sun rises.
A disregard for the social aspects of cooperative programming, manifested as a disdain for all the trappings of communication between developers: comments, documentation, systems of names, explanations, reviews. Here again, some cowboys hang out together, often forming GarageShopEnterprises, sometimes, though rarely, with outstanding results. Apple might be an example.
A focus on "hacking", or perhaps better, "active change". When a Cowboy Coder doesn't like something, he fixes it. It is this dynamic revisionary style which has produced perhaps the best merging of the CowboyCoding and BigDesign approaches. RAD, Incremental Development, the Spiral Model, and even Extreme Programming are all attempts to retain the aggressiveness and passion of the Cowboy while gaining the benefits of risk-aversion that underlies BigDesign.

Sometimes the cowboy is driven by more than a desire to code, by a vision of what could be done. The work can then be elevated to a higher plane of artistry, in aid of some hitherto unattainable goal. If such an individual has sufficient social skills to get along with other developers, some truly great software can be created. University environments often nurture this variant on the beast: a Cowboy visionary surrounded by gunslingers.

Like BigDesign, CowboyCoding is a StrawMan, of course. Few development theorists advocate all of these principles in combination. But then, that's to be expected: cowboys are not development theorists. And yet, most of us at one time or another in our careers have come across people who seem to embody all of these and more.

Both BigDesign and CowboyCoding are pejoratives. It is easy to forget that many of the advances in software are preceded by cowboy experiments showing possibility, and VisionaryCowboy projects showing real feasibility. A cowboy is not necessarily a BadProgrammer; the pejorative nature of the term is related to the difficulty in working with cowboys, not to the quality of the software they create.

I'll also propose that there are some CowboyTheorist?s out here, judging by what I've read on this wiki - people that make up a theory and stick to their guns, and the only process they apply is entering a big barroom brawl anytime someone challenges them.

(That's my theory, and I'm stickin' to it!)

Our cultural heritage in the U.S. gives this image of the loner added cachet, and as noted above, it's all part of a mythology. To quote Wallace Stegner quoting Bernard Devoto in his essay, ''Land: America's History Teacher'' - "One remembers Bernard DeVoto?'s remark that the only true rugged individualist in the West generally wound up at the end of a rope whose other end was in the hands of the cooperating citizenry."

--DonOlson

A slightly less charitable view of CowboyCoding moved to CowboyCoder.

Linux would be one example of a CowboyCoding "organization".

I don't think Linus would disagree.

Well, yes, actually he would. See here: http://www.purists.org/linux/. A cowboy is a cowboy, and it's *always* a bad thing. Even if you work in a team of one, that's no reason not to have coding standards.

Sometimes it works, as it seems to have for Linux, but you need damned good people. -- PeterdaSilva

Actually, Linus spends a good deal of time rejecting code submissions he thinks aren't up to his standards, or don't fit the linux kernel style (a quick rundown of which comes with every kernel in Documentation/CodingStyle). Everything from naming conventions to indentation.

Yes, Linus has to deal with a lot of bad code. But he also receives excellent code -- more than he could ever write alone -- doesn't he?

Of course he does, but that has no relevance at all, being an AffirmationOfTheConsequent?.

2004-04-14: http://www.purists.org/linux/ seems off-line. Could you summarize what you remember was there? At least enough so I could recognize it if I see it elsewhere, and then I could post the new link here?

http://www.purists.org/linux/ is archived at this URL: http://web.archive.org/web/20020803185432/www.purists.org/linux/

Sometimes, to write good code--to find a little motivation, you need to jangle your spurs. I'm at the tail end of a project right now and find I have to slip into cowboy mode for just a little while to get things done right. I've been standing up while I type, pacing around, making rough notes on big sheets of paper, every damn problem my horse catches his heels on. There's a lot of method to the madness, though, and you do end up with very robust, clean code at the end, but there's a degree of madness to the method as well. You let the notes get messy; you don't really think about what you're doing; you just ride. For the bottom half of each hour, I let the compiler catch the typos. And for the rest of the hour I hang up my spurs and the scholarly accountant comes out again. I neatly revise what's been produced. I formalise it, consider boundary conditions, use cases, optimizations, other patterns. But late in the project, as the sun hits the horizon, any real programmer secretly knows there's a little bit of cowboy in all of us. -- LeonBambrick

Be careful not to let a distaste for CowboyCoding blind you to the PracticalRolesOfEgoInTeam.

If a novice at thinking about coding styles (and TDD) could ask a question???

If TestDrivenDevelopment means writing tests to fail, which then determines what you develop next, does that mean that TDD encourages CowboyCoding? My impression is that with TDD, you're not doing up-front analysis to determine what you'll code next or how you'll architect it. So you're just plugging away building your systems, and it's only when you go back and refactor it that you might rewrite it with an encompassing architecture.

On the other hand, does using TDD mean that you CAN safely rearchitect code that's might be considered CowboyCoding, so the end-result is something else?

Or is the fact that TDD is a methodology mean that you're, by definitely not doing CowboyCoding, since CowboyCoding seems to mean you don't use any methodology? After I wrote this, I read the DevelopmentStance page that distinguishes between methodology and style. But I still wonder if this means TDD means you're not CowboyCoding.

Thoughts from the more introspective in this Wiki?

Thanks for sharing,

-- StewStryker?

Hi StewStryker?, my thoughts on TDD in response to your earlier post.

1. TDD ensures that you write just the amount of code that is required to solve the problem at hand and nothing more. At every step of refactoring and fixing failing tests, you're adding just the required amount of code and not code that you assume would be required but may eventually end up as dead code.

2. At the end of the refactoring cycles, not only do achieve the functionaliy that you had in mind (as per your design), but also a whole bunch of unit tests, the advantages of which I will not go into here.

Now, how you begin coding a piece of functionality really depends on you. You could follow a detailed desing document that tells you when you need to plug in a function into your application (so called desing purist), or you could be following a minimalist design where you add code and functionality only when you have a concerete requirement from your product management/customer base (so called cowboy coder).

Like I said earlier, these are just my personal thoughts on TDD, I'd be glad to hear from anyone else who thinks differently :).

- Sheroy Marker

How to get cowboy code:

Get your project done as a fixed price deal with a bunch of consultants.
Agree that your internal developers will take over the project after the first release.
In order to meet delivery timescales (and save face with the auditors) allow the consultants to negotiate down the scope of their release.
Leave the resulting mess (what they couldn't deliver on their own technology, and the hacked mess that they did deliver) to be resolved by your internal staff.
Pay the consultants fantastic sums for "doing x years work in y months" (for large values of x and small values of y)
Settle on a huge plan of "fix" and "enhancement" releases to get to where the consultants should have got to. Let your internal developers sweat over this stuff that the consultants failed to do (or just lied about doing at all).

Result - The cowboys gallop off into the sunset with saddlebags full of gold, whilst G. A. Custer (our valiant team leader) leads us on bravely because somebody in power should have known better.

(Homegrown metaphors for our project include BridgeOnTheRiverKwai and TheSomme?. Team members sometimes whistle the theme from TheGreatEscape?... Yes, we're following a fine British tradition of being calm and collected despite the fact that everything's out of our control.)

--AnonymousCavalryman