When I say “Cowboy Methodology”, most of you are going to laugh. In the programming world, a cowboy is usually a very talented programmer who lives on the wild-side, without rules, fearing no danger. He rides hastily into any situation, guns a-blazing, shouting “yeeee-haaaaw”, then he saves the day and gets (yet-another) hero badge.
The development process used by cowboys is inherently non-formal. So, to think that I could present it as a specific, branded methodology, may seem a bit far-fetched. However, the process used by cowboys always seems to fall into a clear set of patterns. So, for your entertainment or maybe your education, I would like to present the process used by cowboys, along with the pros and cons of following this practice.
Where Cowboys are Made
Ironically, every programmer starts learning how to program, as a cowboy. Think about this: how many of your programming courses contained a one-paragraph description of a completed program, where you had no formal development process, no test group, no project manager, no business analysts and you had a rough timeline that was pretty aggressive? Was there any coding standard or required documentation? Did you have periodic milestones that you had to meet, to confirm that you were on track (if so, did you fudge any of it)? What if you delivered the program with bugs, did you get partial credit? Maybe you were even juggling five other courses at the time and had to choose your own priorities. Did you often coordinate and depend on your colleagues for a major portion of your grades or was it usually just you?
Guess what, this is the cowboy process. You make the rules and you only count on yourself. The process doesn’t matter as long as the end justifies the means. Then you got an “A” and were told to keep up the good work. (Your first hero badge)
So we all start-out with the impression that “the cowboy way-of-life” is the most direct path to success. In school, we probably studied other methodologies, but only used them once or twice. While we were learning, those processes were too cumbersome. When most of us get jobs on a team, we have to be broken of the habits that we’ve formed, and learn to follow a formal, structured practice/methodology. It is hard and feels unnatural. We want to resist it so bad. It usually takes several months or even years to fully appreciate the benefits of turning away from the cowboy process and embrace a structured development process. On the other hand, some of us never really become comfortable with the complexity and distributed control that goes along with non-cowboy methodologies.
Characteristics of Cowboy
When most people refer to a process as being “Cowboy” or call a certain developer a cowboy, it usually is meant to be a gentle insult. This is because, most dev teams, who have outgrown the cowboy process, did-so because they were aware of how unmanageable and unpredictable that process can be. Of course, not all organizations actually do outgrow it.
Here is a brief summary of the Cowboy framework/methodology/practice:
- Need a cowboy (typically, with these characteristics)
- Lots of energy
- Seemingly responsible for everything
- Has very high authority and power
- Probably has a big ego too
- Most likely a ADHD sort of person
- Always coming up with new ideas, but not often completing them
- Get a lot done
- Sometimes errors show-up, and are quickly resolved by the cowboy
- Typically everything is operated in a rushed, panicky manner
- There is a strong resistant to any steps towards becoming more-organized, because there is just too much to do
- Planning is nearly impossible because “what if something unplanned happens?” (and it usually does)
- Cowboys don’t work well with others, because they get in each other’s way
- Quick to criticize others (highly competitive)
- Needs to be validated often
Benefits of Cowboy
Many people make it seem as if the cowboy way-of-life is one of constant danger and cowboys often get their fingers chopped-off (or some equivalent horror). This is not necessarily true. Some organizations bask in the benefits of the cowboy process:
- New ideas constantly arriving
- Nothing is off-the-table, (except stuff that creates bureaucracy: docs, testing, planning)
- Emergencies get handled rapidly
- Cowboys are very dependable, you can count on a true cowboy
- You get a lot done, very cheaply
- Who needs docs? The cowboy knows more, is easier to find, and doesn’t need to be updated/maintained like docs do
Detriments of Cowboy
Since the economics of the cowboy process are so advantageous, why would anybody choose anything else? Well, of course, there are the occasional finger or two getting chopped-off, and the barn-fires and stray revolver ricochets. Beware of these common side-effects:
- It is not scalable. Cooperation between 2+ cowboys is nearly impossible.
- There is no control/check/balance (the cowboy is his own supervisor, he follows his own rules and he believes that he is beyond question)
- Limiting a cowboy’s power/permission will agitate the cowboy and break his process (“Sorry, I can’t do anything today, because I don’t have the permissions that I need”)
- There is no useful documentation (no-time for that kind of noise)
- Paperwork is very scarce (no-time for that kind of noise, either)
- Planning is nearly impossible – stuff gets done when it gets done, no one can give a better estimate.
- Accountability is difficult to establish
- Improvement is only possible within a narrow scope, because it usually conflicts with most of the cowboy processes
How to stick with Cowboy
Believe it or not, it is very easy to use the cowboy processes. As long as you have a reliable cowboy, things pretty-much run themselves. Periodically, someone will come along and suggest that you “grow up”. If you don’t want that to happen, you will probably employ these tactics:
- Prevent the organization from growing (remind everyone: things could be worse, you know)
- Prevent others from analyzing the code, processes, docs, (pretty-much anything that the cowboy owns)
- Campaign for the merits of the cowboy process
- It is fast
- It is cheap
- Campaign against anything that is not part of the cowboy process
- Everything else is stupid
- Your cousin’s employer does the other stuff and he hates it there and they constantly fail
- You tried it before and it won’t work here
- Only control-freaks follow the other practices
- Actively or passively refuse to comply with any other processes or practices. When you help them fail, point out the failure “See, I told you it would fail”.
- If you need to add people, create zones of operation with little or no-overlap (each zone is owned by 1 cowboy: no cooperation needed)
There are MANY organizations who are fully immersed in the cowboy process. Even a significant number of Agile shops are really just semi-structured cowboy practices. In fact, Agile is usually the first step that an organization can take to move towards a more formalized approach, while still allowing a cowboy(s) to operate.
So, rather than denying what you really are, it is much more healthy to acknowledge if you are a cowboy shop. Then it is much easier to identify what will or will-not work for your team. You can also understand the inner workings of your team and process and understand how to deal with it more effectively.
If your organization is hurting from the effects of the cowboy methodology, you already know that you will have to change. That is a real can of worms and I will discuss it another time.