Galhano //127.0.0.1

Cowboy Coder

Cowboy Coders are programmers who write code according to their own rules. They may be very good at writing code, but it doesn’t generally follow the standards, processes, policies, or anything else derived from the group. Cowboy Coders work well alone, or in the old-style CaveProgrammer environment, but they rarely, if ever, work well in a team. Often times, they are a burr in the saddle that keeps the team from getting positive work done.

The above elicits mixed emotions. I have often been a CowboyCoder; in some circumstances I didn’t have a choice (I was the *only* coder on the project); in others, it was inherent in the context : no team rules, standards, or processes, and a division of labor which put senior developers in charge of different projects, with little opportunity to elaborate such standards as a team. I didn’t like having the pattern thrust upon me, and I’m pretty sure I’ll do much better in a team.

CowboyCoders are identified more by their attitude than by their circumstances. CowboyCoders prefer — nay, insist! — to avoid standards, processes, and policies, and hate working with others.

Some CowboyCoders work in packs as GuerillaCoders, self-supporting their behaviors. See RamboCoder.

The Cowboy Way:

• 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.

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. This problem is either caused or worsened by the ItAintBroke attitude that our management fosters, combined with the distastefulness of working on the 10 year old code in our codebase. Maybe if they were in an environment where communication, collaboration, and refactoring was encouraged, they might change their tune.

Shoot First Ask Questions Later

The ShootFirstAskQuestionsLater AntiPattern is practiced during CowboyCoding in order to get a working prototype done before DesignByCommittee bureaucrats can bloat the code with all their stupid features. I have often encountered the situation where our business analysts say we need a veeblefetzer. OK, tell me what this veeblefetzer look like? Umm, we don’t know, we never had one before. So how am I supposed to write one? Well, you’re the programmer. How about I make one up, and you tell me what’s wrong with it? Yeah, let’s do that.

How is this common combined coding and analysis prototyping pattern different from ShootFirstAskQuestionsLater?

The above example is not ShootFirstAskQuestionsLater because you asked them the question first, or you communicated assertively. If you had just seen veeblefetzer on a document and said, “Oh, he doesn’t know what he wants anyway, I’ll just code it up and see what he thinks,” then you are practicing ShootFirstAskQuestionsLater. You might get it correct or you might shoot the good guy. –TimBurns

Lone Ranger Coder

A CowboyCoder that gives up his unstructured style of development, gets real skills and experience, perhaps joins a development team, and comes back to a project as its sole developer may be a LoneRangerCoder.

Working with only the help of a QualityAssurance sidekick, he rights the injustices of bad design and poor quality code with unflinching morals, and a steady hand to guide his development tools.

Seeing his situation and having grown in wisdom he will apply the best AgilePrinciples and AgileProcesses where they are applicable.

Proposed by someone speaking from experience I guess?

It sounds like a pure fantasy that management would let one developer and one QA person control a project, since it isn’t possible to plan or test without a manager and architect present. It’s especially suspicious that a developer is allowed to question an outside party’s design.

Well the requirements are handed down from on high, of course, and they are to be respected. If the project is small enough then there really can be a solo developer doing the design and coding successfully within the bounds of the requirements.

I was kidding. About needing a manager and architect to do any planning or design. Sarcasm. (If you’re being sarcastic too, you’re way off my radar.)

Of course, a LoneRangerCoder could be a programmer who works with Indians, but only the good ones.

* “Don’t worry, Tonto! We’ll survive the review about that bug that killed sixteen users.”
o “What do you mean we, white-man?”

To beat this metaphor to death, what is his SilverBullet?

“In addition, the Lone Ranger decides to use only silver bullets, as a reminder of his vows to fight for justice, and never to shoot to kill.” Since Brooks’ silver bullet is the opposite of the Lone Ranger’s, we could leave this page with just the potentially offensive Indian jokes.

Also, it violates OnceAndOnlyOnce to shoot a man to wound him just so he can be executed later. In all honesty, the lone ranger resembles a soft-touch manager like Rands more than a programmer. That suits me fine; it sounded to me all along like this “Coder” is a manager without any programmers to boss around.

Agile Principles

• EarlyAndContinuousDelivery? – Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• WelcomeChangingRequirements? – Welcome changing requirements, even late in development.
• HarnessChangeForAdvantage? – Agile processes harness change for the customer’s competitive advantage.
• DeliverFrequentWorkingSoftware? – Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
• BusinessDeveloperCooperation? – Business people and developers work together daily throughout the project.
• MotivatedBuild? – Build projects around motivated individuals.
• TrustSupportEnvironment? – Give them the environment and support they need, and trust them to get the job done.
• FaceToFaceConveyance? – The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
• SuccessIsWorkingSoftware? – Working software is the primary measure of progress.
• SustainableDevelopmnetProcess? – Agile processes promote sustainable development.
• SponsorDeveloperUserPacing? – The sponsors, developers and users should be able to maintain a constant pace indefinitely.
• ExcellenceInTechnicalDesign? – Continuous attention to technical excellence and good design enhances agility.
• KeepItSimpleMinimalization – Simplicity — the art of maximizing the amount of work not done — is essential.
• BestTeamOrganization? – The best architectures, requirements and designs emerge from SelfOrganizingTeams.
• ReflectTuneAndAdjustRegularly? – At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

 ManifestoForAgileSoftwareDevelopment