Most programmers defending methodologies politically correct like Agile, Waterfall, RUP, etc. Some of them follow the methodology but not all of them. Frankly, if you can choose the methodology, you certainly would go to mainstream "correct" methodologies or you would prefer the "easier" methodology like cowboy programming? Why?

I know it depends. Please, explain when you would use one or another. Please, say what advantages do you see on Cowboy coding.

See about Cowboy coding on Wikipedia

  • 15
    An experiment was performed once with two groups of people who were asked to make clay pots in a fixed time frame. Group 1 were told to make the highest quality pot they could, group 2 were told they would be measured on the weight of all the pots produced. The quality of the final group 2 pots was higher than the group 1 pots. Alas I have not been able to find the original source of this experiment, but the overriding point is "the higher the number of iterations, the better the quality". Were group 2 cowboys? Probably. Commented Sep 25, 2010 at 12:42
  • 3
    "Cowboy coding" a terrible choice of words if nothing else. When used to refer to people in a team "cowboy" often means something along the lines of "the person who just does their own thing and doesn't care what that means for the rest of the team". But the question of the value "less structure" is a good one.
    – MIA
    Commented Sep 25, 2010 at 15:40
  • 4
    I think you should put your definition of cowboy programming (directly) in your question as both the wikipedia page and answerers seem mixed on what really is cowboy coding. Do you mean just not to use any methodology? Because lots of people seems to think that cowboy coding doesn't do design at all. At least for me it just meant no formal process - not that you jump coding straight away. I think since you're the one asking the question you should define it according to what you wanted to know.
    – n1ckp
    Commented Oct 10, 2010 at 20:50
  • @n1ck: Thanks. Some people just jump in the answers without understand the question. It's too late now, change it would invalidate some answers. Unfortunately some user didn't get the question. You got it.
    – Maniero
    Commented Oct 10, 2010 at 22:14
  • Does this person not use any sort of source control system, or just refuses to use the company's?
    – Thomas
    Commented Jun 11, 2011 at 5:46

25 Answers 25


I think almost every experienced programmer has gone through three stages and some go through four:

  1. Cowboy coders or nuggets know little to nothing about design and view it as an unnecessary formality. If working on small projects for non-technical stakeholders, this attitude may serve them well for a while; it Gets Things Done, it impresses the boss, makes the programmer feel good about himself and confirms the idea that he knows what he's doing (even though he doesn't).

  2. Architecture Astronauts have witnessed the failures of their first ball-of-yarn projects to adapt to changing circumstances. Everything must be rewritten and to prevent the need for another rewrite in the future, they create inner platforms, and end up spending 4 hours a day on support because nobody else understands how to use them properly.

  3. Quasi-engineers often mistake themselves for actual, trained engineers because they are genuinely competent and understand some engineering principles. They're aware of the underlying engineering and business concepts: Risk, ROI, UX, performance, maintainability, and so on. These people see design and documentation as a continuum and are usually able to adapt the level of architecture/design to the project requirements.

    At this point, many fall in love with methodologies, whether they be Agile, Waterfall, RUP, etc. They start believing in the absolute infallibility and even necessity of these methodologies without realizing that in the actual software engineering field, they're merely tools, not religions. And unfortunately, it prevents them from ever getting to the final stage, which is:

  4. Duct tape programmers AKA gurus or highly-paid consultants know what architecture and design they're going to use within five minutes after hearing the project requirements. All of the architecture and design work is still happening, but it's on an intuitive level and happening so fast that an untrained observer would mistake it for cowboy coding - and many do.

    Generally these people are all about creating a product that's "good enough" and so their works may be a little under-engineered but they are miles away from the spaghetti code produced by cowboy coders. Nuggets cannot even identify these people when they're told about them, because to them, everything that is happening in the background just doesn't exist.

Some of you will probably be thinking to yourselves at this point that I haven't answered the question. That's because the question itself is flawed. Cowboy coding isn't a choice, it's a skill level, and you can't choose to be a cowboy coder any more than you can choose to be illiterate.

If you are a cowboy coder, then you know no other way.

If you've become an architecture astronaut, you are physically and psychologically incapable of producing software with no design.

If you are a quasi-engineer (or a professional engineer), then completing a project with little or no up-front design effort is a conscious choice (usually due to absurd deadlines) that has to be weighed against the obvious risks, and undertaken only after the stakeholders have agreed to them (usually in writing).

And if you are a duct-tape programmer, then there is never any reason to "cowboy code" because you can build a quality product just as quickly.

Nobody "prefers" cowboy coding over other methodologies because it isn't a methodology. It's the software development equivalent of mashing buttons in a video game. It's OK for the beginner levels but anybody who's moved past that stage simply won't do it. They might do something that looks similar but it will not be the same thing.

  • 32
    Beautifully articulated.
    – Brandon
    Commented Sep 25, 2010 at 14:57
  • 4
    +1 for good contribution despite the contradiction. You said a quasi-engineer do conscious choice when is needed. Many times experienced programmers with knowledge need to choose break the rules that he know and believes due to some constraint. Of course if a programmer is a damn good and quick on his work, he don't need choose, but few professionals have this quality. Anyway, the question is provocative.
    – Maniero
    Commented Sep 25, 2010 at 15:18
  • 17
    The problem is too many people want to be duct tape programmers without being Architecture Astronauts first and then quasi engineers, which means they are forever Cowboys. So, I think I can point at that list and say "it looks like a career progression" ... too bad the management types think AAs are the pinnacle.
    – MIA
    Commented Sep 25, 2010 at 15:46
  • 24
    I don't even know where I am on this list :S Sometimes I can hear about a project and know instantly how I'm going to build it, like 4, and then I'll suffer serious analysis paralysis and over think the architecture, like 2, then I consider YAGNI and think about business value and try to be pragmatic, and feel like a 3, and then I wind up making a mess like a 1. Commented Aug 11, 2011 at 5:05
  • 15
    I should give you -1 for implying that a highly paid consultant is on duct tape programmer skill level (hint: most of them aren't, not even close). But I gave you +1 anyway.
    – Falcon
    Commented Jan 21, 2012 at 11:28


I also prefer leaving my socks on the floor where I took them off, my desk covered in printouts and old snack wrappers, my sink full of dirty dishes, and my bed unmade.

I don't consider a vacation planned in advance to be a proper vacation, a meal eaten with a mind toward nutrition proper food, or staying on known trails proper hiking.

I like to have fun, be surprised, learn new things, make mistakes, and never be quite sure if I'm going to make it back. And sometimes, that attitude is exactly what's required to get a project off the ground...

...but most of the time, it's just irresponsible. When the dance ends, the piper will be paid... Forget this at your peril.

  • 1
    I am having trouble +1 for "old snack wrappers, my sink full of dirty dishes, and [most importantly] my bed unmade." What the heck, +1 because the thrill of cowboy coding and the discomfort from not knowing if you can make it back is too empowering to waste time with silly UML, design and specifications. They write their specifications from my implementation, NEVER the other way around. ::sarcasm
    – Chris
    Commented Sep 25, 2010 at 2:24

This really comes down to the question of whether or not you can implement things correctly without a tight structure in place and lots of time eaten up in planning.

I'm going to throw something out here on this one that may be really unpopular: customers generally want things handled in a cowboy fashion.

That is, they want to request something get done, and have someone jump on it, execute it, and get it out there. No project management, meetings, conference calls, or forms. Just do it. I've never had a customer say "hey, this was done a little too quickly for our tastes, we'd appreciate it if you would put a little waterfall or something in there next time".

Team methodologies and structure are designed to level the playing field of a project and get varying levels of developers on the same page, working for the same goals, in the same ways.

The successful "cowboys" that I have worked with are able to:

  • Identify the simplest way to implement something quickly
  • Know at what point it will break
  • Write clean, readable, and straightforward code
  • Predict how the users will use it, abuse it, and break it
  • Scale it / abstract it in the right places, and not go architecture astronaut on it
  • Know where and how to handle edge cases and exceptions

People like this produce truly great results with very little management and structure overhead, but they are rare.

  • 11
    I really wouldn't call your final list "cowboy" coding. It's more like the quintessential "duct tape programmer" glorified by Spolsky. The difference is, a cowboy coder just starts slinging code together without paying any heed to overall design; the "duct tape programmer" sort of makes it up as he goes along, but still has a plan; he's just doing most of the design work at an intuitive (and sometimes iterative) level.
    – Aaronaught
    Commented Sep 25, 2010 at 13:52
  • 3
    Customers doesn't necessarily want it cowboy-style, they just want it cheap and fast. It is then up to us to deliver.
    – user1249
    Commented Dec 3, 2011 at 23:03
  • @user1249: That reminds me of the project management triangle: cheap, fast, good - pick two.
    – DanMan
    Commented Aug 27, 2016 at 19:19
  • 1
    The assumption that the customers are the professional authority is laughable. Ofcourse I want stuff to be handled in a cowboy fashion, that's why I want my car to be done quick and dirty, my house to be build by newcomers who can just stick cement in a wall-like fashion, and my food should be prepared by those who ignore health risk at the benefit of me eating sooner... Commented Feb 6, 2018 at 13:14
  • there are plenty of customers of McDonald's, but does that mean a gourmet chef can get away with flipping frozen burgers on a griddle and serving them to a michelin guide critic? Quality costs extra, in every field. Commented May 6, 2020 at 11:48

You're exactly correct. This "cowboy programming" approach may get the first revision of the code out faster, but that time savings will be more than lost thanks to:

  • Additional bugs
  • Additional time needed to find the bugs you would would have had anyway
  • Having to reverse engineer your code to remember what you did when you need to make a change in six months
  • Extra time spent training additional developers that need to work on your code
  • Not having a log of revisions to look back to when you make a change that breaks something
  • Not having modules you can easily reuse in later projects
  • And on and on and on

Like Neil Butterworth mentioned in his answer, sometimes you gotta do what you gotta do. As a general practice though, no, banging out code as fast as possible with no time spent on source code control, patterns, documentation, etc. is a very bad habit to get in to.

Good for you for analyzing your coworkers and considering whether their habits are beneficial or harmful instead of blindly doing as they do.

  • 7
    There are always exception. Some coders might be geniuses, have photographic memory but little patience. Others are not that fast but persistent; they grind away at the task one byte at a time until it becomes their bitch. There are many ways to be a good programmer. Maybe cowboy programming works for her. It might not work for the asker or many others. However, why mandate HOW someone should work , when the important thing is the rate and the quality of results. Why pass a law prohibiting 12-cylinder engines, when you can simply reward higher mpg through tax credit?
    – Job
    Commented Jun 11, 2011 at 1:54
  • @Job: I agree. Everyone has a different process; this process is not commonly successful but can be. I for one am a notorious user of the Feynman Algorithm, and I do step 3 as fast as possible while I'm still in the zone.
    – Jon Purdy
    Commented Jun 11, 2011 at 5:22
  • 4
    @Job - There are sometimes exceptions. The percentages will eventually take over. There might be exceptions when evaluated in isolation of perfect code (no errors, no problems, etc) but eventually cowboy coder habits will hit her company (and her team, and her) in the butt. You might win at Russian roulette five times in a row but keep playing and my money is on the bullet.
    – Thomas
    Commented Jun 11, 2011 at 5:31
  • 2
    @Job: Yes I sort of agree, up to a point. But refusing to consider anything else (which = refusing to learn), and refusing to use source control are two big red flags that say to me: Might be fast, but a real dangerous boofhead. Commented Jun 11, 2011 at 8:36
  • 1
    Following a formal process isn't the only way to write quality code, and doesn't guarantee quality code anyway. Having a formal process is less important if a persons work is "loosely bound" with other peoples work. Version control, if anything, gets more important as the process gets more informal, though. On "refusing to learn" - how many bad experiences has this person had with bad processes and bad systems in the past? Inference is imperfect, but it's basically the only way we have to understand anything outside our own heads, and with the right (or rather wrong) experiences...
    – user8709
    Commented Jun 11, 2011 at 19:15

It completely depends on whether I'm working solo, or in a team.

If I work in a team, some conventions and agreements are required - everyone in the team must follow some commonly agreed standard to work towards the common goal so that their efforts are compatible.

But if I work alone, then of course I want to be a cowboy. All great creations in the world have been invented by a single mind, or at most two, working cowboy-style. Just to name a few:

  • Classical mechanics? Cowboy Isaac Newton, later additions from Leibniz, Lagrange, Hamilton.
  • Airplane? Cowboys Wright.
  • Theory of relativity? Cowboy Albert Einstein.
  • Fundamental science of computers? Cowboy Alan Turing.
  • Transistor? Cowboys Walter Brattain and John Bardeen.

Teams are good at making incremental improvements and putting together new systems based on proven recipes fairly quickly (provided that they're being led well), but it's rare to hear about an actual invention made by a team. Team work and the methods it requires have their virtues, but so does cowboy coding.

  • I notice that you mentioned some famous cowboy successes while passing over the far more numerous cowboy failures.
    – Mawg
    Commented Feb 27, 2015 at 11:04

EDIT: For future reference, my answer is for another question, which has been merged into this one. It's quite out of place here, but that was not my call.

She's just lazy, arrogant, ignorant and extremely selfish. This behavior is reckless.

I mean, it's not that she uses an unconventional or maybe outdated methodology. She just consciously uses none. No standards. No quality assurance. No whatsoever. Where does she expect software quality to come from? Trees?
It is funny she actually denies the experience of the people you quote, when she quite obviously lacks it. Providing verifiable and relevant arguments to question their claims is valid. But just trying to discredit them by denying their experience is not.

But, the main point is: How much time does version control take?
If she cannot be convinced to invest the 5 seconds every now and then, you should take it up to her boss. Version control is not optional. Full stop.

And once you have her using version control, you can easily track which bugs she introduced. And let her fix them. It's her mess, why should you clean it up? If she thinks her approach is better, then let her do it - all the way.
Assuming she actually can do it (within reasonable time), you still have a problem: teamwork with her is close to impossible. And this is something you will have to solve by either convincing her (which sounds unlikely), making her leave (for the sake of your company) or leaving (for the sake of your sanity).
But her failure in the first place is far more likely and should definitely prove your point. And then she'll start adhering to best practices as many people with a lot of experience do.

  • 2
    Sometimes the truth hurts plain and simple... Commented Jun 11, 2011 at 17:42
  • +1 for saying that teamwork with such selfish people is impossible. Even if they are genii, cowboys are not team players; they are the main show & we are the backing group
    – Mawg
    Commented Feb 27, 2015 at 11:02

It depends on circumstances. For example, after some disastrous trading scandals, several electronic stock exchanges insisted that auto-trading flags were added to all trades. And this had to be for all trading software inside a week. I mean it had to be done - if the flag wasn't there you couldn't trade. In circumstances like that, all good practices go by the board - you just have to go (as we used to say) "hacky, hacky, hacky". And in those circumstances, writing code fast and accurately is key. Particularly as there were no test systems available.

  • How does one use your SWINE? What is the language for describing dialogs?
    – Job
    Commented Jun 11, 2011 at 2:05
  • @Job It ain't ready yet. Commented Jun 11, 2011 at 2:14
  • your answer completely skips over the most telling part of the question "I have a programmer that codes fast by dismissing revision control ..." I am pretty sure your example, they didn't dismiss version control or release management, etc.
    – user7519
    Commented Jun 11, 2011 at 3:31
  • @Jarrod Version control. Well, we had rcs. Release management? This was an investment bank! You push stuff out the door as fast as you write it. Commented Jun 11, 2011 at 8:43

Depends on the problem. A good senior developer will write very compact, simple, and robust code that's very stable and uses all best practices without churning through pages of documentation and tons of different patterns and paradigms. But he will also know when he can afford to do such things.

I would be shocked if he would take a new problem and start to design an application that requires man-months from scratch. But if it's a plugin, simple tool you can write in 2 hours, a function that does some conversion and is not intended for a reuse, design and patterns are actually only good for wasting the time.

Also, I guess large part of the design was already processed in a background thread somewhere inside the senior developers head.

You have to start worrying when the senior developer starts churning classes of a complex system, or new applications from scratch, and without planning step.

  • 9
    your answer completely skips over the most telling part of the question "I have a programmer that codes fast by dismissing revision control ..." anyone that dismisses revision control and promotes this opinion to junior level employees is criminal.
    – user7519
    Commented Jun 11, 2011 at 3:29
  • 1
    @Jarrod: or not. There's little point in committing incomplete/dysfunctional code. Commented Jun 11, 2011 at 18:03
  • 1
    @Denis - that's mostly what a branch is for. The history of decisions, changes, mistakes, dead ends etc during the development of incomplete/disfunctional code is IMO a part of the documentation of that code, and very important during maintenance. Easier branching and merging is a good reason to replace subversion with a distributed VCS.
    – user8709
    Commented Jun 11, 2011 at 19:46
  • @steve: That would assume you're looking into the logs before editing a line of code. Quite frankly, I know very few coders who actually do... And even then (as I do...), they're a lot less interested in why this/that was committed rather than that, than in why it was changed from the original code. Commented Jun 11, 2011 at 20:06
  • @steve: For simple functions it's easier to use single commit with comment "Added function that calculates acceleration parameters", than to have coomits: "PaternX skeleton", "Added first line of code", "Fixed a bug", "Fixed another bug". It's easier to track global changes of the project if there are less "noise" commits. And there are shelves that can be used for incomplete code to avoid dataloss.
    – Coder
    Commented Jun 11, 2011 at 20:24

From my experience, cow boy coding WITH source control is the best and most bug free way to develop large software systems.

  • 2
    At the cost of creating a big ball of mud (my own answer ;-)) Commented Jun 11, 2011 at 18:00

This kind of person is called a hacker, and it's usually not a complimentary term from the more professional among us.

As you've noticed, the time saved in design, organisation and control is lost in debugging. And often in finding which release of code was the one that was actually shipped. If you can find it at all!

I find this kind of person is too wrapped up in themselves, think they're too good to work with the 'limitations' others have to suffer and so don't bother with them, and that loses even more time as the rest of the team has to clean up after them. They are also not too involved in the bug-fixing process (that's a maintenance developer's task, well beneath the 'l33t coder's skills and talent).

So, it might be a common approach elsewhere, but at my place (and I'm a senior coder who has tendencies to this approach, ahem) we do not suffer it. It's not that we demand a ton of processes and procedures, but we do insist on a minimal amount of organisation, source code control (which to be honest is bloody east and damn useful!)

Kent Beck et al, are all professionals who saw the old process-laden ways were bad in themselves, so they created new methodologies to organise coding while still keeping it more craft-oriented, and then told everyone else about it - by publishing books (how else did you do it back then before the Internet?)

You sound like you have it right - do not accept poor practice just because someone else can't hack it. Your team lead or manager should be coming down hard on this 'rockstar', but if they're not.. well, that still doesn't prevent you from doing the right thing. Just do not accept shoddy practice from her, if she screws up (and she will!) then let her clean it up. You stick to good practices (and you know what they are) without letting them take over to the detriment of your coding productivity, and you'll be good for the future.

Here's an essay from a truly insightful writer. It doesn't fix your problem, but it does give you a few insights into why it's like it is and maybe a few tips to deal with it professionally.

  • +1 It's unfortunate that 'hacker' has changed to mean this. A Brief History of Hackerdom Commented Jun 11, 2011 at 0:26
  • 4
    I'd say "hack" instead of "hacker". Commented Jun 11, 2011 at 3:45
  • 2
    They're a cowboy, just as the OP stated, don't go muddying up what a hacker is. Leave that to the media.
    – ocodo
    Commented Jun 11, 2011 at 4:41
  • it could be they're a "rockstar" programmer ... too full of ego and talent to worry about the 'little things'. Now where's my bathtub full of blue m&ms?! I want it NOW!
    – gbjbaanb
    Commented Jun 11, 2011 at 13:40

I think one of the commentators had it right - its all about the results.

If the person can produce a good product - something that does what its supposed to do, and is maintainable and reliable - then what does it matter if formal methodologies or processes are followed? Processes are great to ensure a floor in quality, but if someone's working above that floor already, then the processes add nothing into the equation. Too many developers these days, imo, seem to think the point of programming is to adhere to processes, as opposed to producing a good product.


You might find some insight in my answer to Frankly, do you prefer cowboy coding? The trouble is, "cowboy coding" means different things to different people, and it's not immediately obvious, to the untrained eye, which version you're seeing.

When somebody can look at a problem and immediately start belting out code, quickly and accurately, that may be the sign of a master engineer who has seen it all a thousand times before and already knows the best way to solve the problem.

Or, it may be the sign of a rank amateur.

I will tell you one thing: Refusing to use version control or write tests because they are too "academic" is definitively not a "senior" or even remotely professional approach. You will never, ever see this kind of thing being done at a major software shop such as Microsoft or Google, and will probably not see it in most startups or reasonably mature enterprise teams either.

The risks are just too great. What if your PC dies overnight? Bye bye 3 years of productivity. Okay, so you make backups; then what happens when you make a major change, realize that it was completely wrong, and have to revert it? This happens even to the most experienced and talented of developers because the requirements are wrong. If you're not running any kind of version control, you're just going to be spinning your wheels in the mud. I've been there, once, and would never go back.

There's just no excuse - it takes 10 minutes to set up a repository and 10 seconds to do a commit. It makes up maybe 1% of your total development time. Tests, if you're in a hurry, can easily be whittled down to 20-30 minutes a day and still be reasonably useful.

I'm no fan of Agile (note the capital A) methodologies but sometimes you really do need to just roll up your sleeves and start writing the damn code. I've seen people and teams with "analysis paralysis" and productivity really does take a visible hit. But dismissal of the basic tools of our trade such as revision control and tests is really the clincher for me; this person does not belong in a senior position.


The only important fact is the long term product results of the team.

There is a claim that a team including one great programmer (or more) will produce better results than a team with an even larger number of average programmers coding at an average rate.

If the cowboy produces stuff that the regular programmers don't (for a given deadline or spec), and the team with the cowboy even has to spend a few man weeks/months cleaning up the cowboy's mess, they might still end up with the better result sooner.

If the team with the cowboy can't clean up (document, debug, integrate, maintain) the mess even after many man months/year's, then whatever advance the cowboy created did not give the team a long run advantage.

Decide which, and optimize the team's roster.

Not every programmer works (or should work) the same way, as long as the end result is good.

  • 4
    There is a claim that a team including one great programmer (or more) will produce better results than a team with an even larger number of average programmers coding at an average rate - That is until the great programmer leaves and takes their saddle, horse and your code with them. How good do those results look then?
    – Thomas
    Commented Jun 11, 2011 at 5:38
  • The assumption is not necessarily correct. Meeting a deadline of a conference or another show of your product can be extremely important too.
    – user1249
    Commented Jun 11, 2011 at 5:50
  • 1
    @Thomas : Risk factors cut both ways. The guy financing all the paychecks could walk out of the next funding round when even a hacked-together proof-of-concept doesn't appear soon enough. How good do your slow horses look now? All engineering choices are gambles. Place your chips.
    – hotpaw2
    Commented Jun 11, 2011 at 6:16
  • 1
    @hotpaw2 - The gamble is whether the (potentially terminal) costs from cowboy coding will hit before you are able to get your funding. In general, my bet is against cowboy coding (and that it will take longer). Oh, you might beat me 1/10 times or even 1/5. But taken in total, year after year as the chances pile up, cowboy coders will cost you more than you gain.
    – Thomas
    Commented Jun 11, 2011 at 6:21
  • 2
    @Thorbjørn Ravn Andersen, @hotpaw2 - There is another dynamic at play here. A coder that is willing to use, if not actively pursue, risky techniques, even when those risks are unnecessary, is in general going to make riskier choices elsewhere. I.e., their choice against source control is indicative of a riskier pattern of behavior that will eventually bite them and their company. Even in a gamble, sometimes you can beat the house but eventually the percentages beat you down.
    – Thomas
    Commented Jun 11, 2011 at 6:26

Yes, but you have to recognize when NOT to do it.

On anything small you are probably fine, but if you have something complex, dangerous, constrained, etc you need to be able to recognize when a proper design is worth the extra time.

I also think you should definitely think through Aaronaught's answer. Cowboy means different things to different people.


When I think "traditional" methodologies, I think "management doesn't know how to understand developers, so instead of coming into the developers world and understanding enough to know what's going on, they make the developers come into their world".

Fundamentally, when I think of "Agile", I think "you do what you need to do to minimize the inefficiencies introduced by multiple people working together." So I'm firmly in the camp that "there's no such thing as THE Agile Methodology, just a set of values and principles".

In other words, there are things you need to do on a very large project, and there are things you need to do on small projects, and there are things that you do on both.

For example, I would not have more than the simplest of backlogs for a project I'm working on myself... It would just be a to-do list. If there are two of us, I'd probably have that list shared, but in a very simple format (probably just a note stored in our code repository). Once I have 3 or 4, I'm looking for some sort of work item system.


Only when prototyping of very simple features.

Then once done and considered the right way, I ditch the code and get serious.


I've done it once on a real project (at the time we called it Samurai Programming, after the Samurai Tailor series of sketches on Saturday Night Live), and much to my amazement, it worked out well. Of course, what I started with was garbage, so there was little risk of making it worse.

However, I am a "neat" at heart and dislike the shoot-from-the-hip style of development.

On the other hand, heavily process-laden modus operandi is not to my taste either. I just like to plan before I act.

All in all, I feel that the amount of formal process that is appropriate depends heavily on the magnitude (size of the code, duration of the project, number of developers, kinds of requirements, etc.) of the project. I want rigor and strict criteria to be imposed on people developing the software for avionics or biomedical equipment, e.g. For games, e.g., there's far less down-side to any failures, so the cost and burden of rigorous and methodical development practices is not really justified.

  • 2
    Frequently you need to solve the problem in order to figure out how to solve it...
    – user1249
    Commented Dec 21, 2010 at 21:18

It depends (heavily) on the size of the project. On one hand, to get a decent result you need to have a design. On the other hand, if the project is small enough that you can conceptualize the entire design (are most of it anyway) without writing it down, drawing diagrams, etc., then you're probably just as well off without that extra work of documenting everything you do.

Almost everybody has heard enough horror stories to realize that trying to jump in without a clear idea of what you're doing and where things are going is a recipe for disaster. What's far more rarely pointed out is that the opposite can be equally disastrous. Just for example, most of us routinely write small tools in the process of programming. Writing a complete specification, tests, documentation often just isn't worthwhile. There's a threshold below which productization isn't worthwhile -- people often dislike reinventing the wheel, but in some cases it's easier to reinvent than avoid it.

In cases like this, what's often is worthwhile is productizing a library to make tasks like this easy. With that, the front-end code often becomes so trivial that writing (or modifying) code to do what you want becomes easier than sorting out how to get a complete program to do what you want. Consider, for exmaple, gnu indent with its 50+ different flags, many of which interact in various subtle ways, so about the only reasonable choices are 1) don't use it at all, or 2) decide to like what it gives you instead of trying to get what you originally wanted.


There appear to be two camps - those who favour results, and those who favour principles. I fall into the latter.

I am a mediocre but arguably conscientious programmer - my main concern when coding, beyond getting the job done, is that I am helping whoever uses my code to get THEIR job done. I can't say as that I've always achieved that - but that's what I aim to do.

Sure, you may have a hotrod on your team - but what happens when they take a couple of weeks leave and you're asked to debug their work, or add stuff to it? Ultimately, cowboy programmers are not team players. They may make great code, but if the team depends on them - then it's dangerous.

  • Yes, and it is possible (likely?) for some cowboy coders to deliver not-so-great code.
    – Bernard Dy
    Commented Jun 11, 2011 at 19:37

No, never.

I always do requirements analysis, think about architecture, design the details, and then code. Even if I work solo at home for a personal project.

And I would instantly fire a developer in my team if he/she were working in a cowboy style. We are engineers and have a responsibility with the customer and the users.

  • -1: You also must act in the best interest of whomever is writing your paycheck.
    – Jim G.
    Commented Dec 22, 2010 at 4:32
  • @Jim: I am writing the paycheck. That's why I have the prerrogative to fire members of the team. Maybe your downvote was a bit hasty. :-)
    – CesarGon
    Commented Dec 22, 2010 at 17:52
  • We are engineers and have a responsibility with the customer and the users. - Sometimes the customer demands a quick ship date. Emphasis: Sometimes the quick ship date is non-negotiable.
    – Jim G.
    Commented Dec 24, 2010 at 21:58
  • @Jim: I know that very well, after having started up three companies. Still, no cowboy coding ever, thank you very much. As I said, we have a responsability with the customer and the users, and I have always been able to match that commitment with sound engineering practices and no cowboys.
    – CesarGon
    Commented Dec 26, 2010 at 17:06

I don't think cowboy coding is a senior approach.

As others have said, there's a real danger in discarding version control. Skipping documentation and analysis could also mean risking delivery of something the user doesn't want. Just my opinion, but I don't think you go from "coder to developer" if all you do is cowboy code.

However, yes, there are exceptions like the one Neil Butterworth mentions. And in these situations, I'd rather have an experienced senior developer be the one that has to do the cowboy coding.


Cowboy programming is a rather sure way of creating a big ball of mud. Which, as unpleasant as it sounds, tends to deliver...


I think newer programmers tend to do some cowboy coding things when taking on aspects of a project / scopes that they may not have a lot of experience with or when they are trying to "just get things done" due to pressure from a boss, etc. I know I have definitely gone down this path a few times because I was lacking in knowledge of the proper pattern to use and just "hacked my way through it".

The difference between me and the person you are complaining about is that I usually soon after realize that I could have done it better and made it more maintainable and it usually spurs me to learn more and improve my skills (by reading books / articles on the subject). When I go back to debug some of these hacked solutions I usually find it to be a pain and it contributes more to my wanting to learn how to do it the "right way". I think this person you are describing is basically stuck at an infantile level of self reflection and it letting their own ego get in the way of actually improving their skills as a software developer, doesn't seem like someone I would want to work with.


I have the feeling that your distaste for her style is causing you to slightly misrepresent it. You say the cowboy approach is paid in debugging - is this what is already happening, or is that your assumption of how it will play out?

Fair disclosure - I am a senior developer myself, and I often forgo a formal process for design and going on experience. Not having a formal process for someone who is very experienced in the problem domain is quite common. If you have solved a problem dozens of time, you don't need a formal process to formulate a similar solution again.

A formal process deals with the design of code - I don't see why more bugs should be introduced because a formal process is missing. The only big problem I read in your account is that revision control is not being used - which is not only selfish, but downright reckless on the developer's behalf. Is she in fact not committing at all, or just not committing in a pattern that is to your liking?

Not having a formal approach to design is not 'cowboy coding' in my book (not using revision control is though). Experience should be used for exactly that - to reduce time needed to come up with a 'good enough' solution. Remember, you have to solve the problems you have currently and make the code easy to change, not design for future scenarios that might never happen. With experience you get a good feel for how to do that very fast.


I find your post interesting. I've often shared views with your subject, and her feeling is that over-formalized methods are stifling. As someone else noted, if she's a genius and can track a multitude of mental notes at the same time without forgetting or getting confused, then it's quite possible to maintain a monolithic chunk of convoluted code and get it to do amazing things with completely obscure changes. There's a certain mental happiness that comes to the brains of people that can do that - it's like being a God of a little universe in your mind.

However, smart employers have learned the hard way that nobody but the original author can ever do anything worthwhile to that code. If the programmer moves on, they end up wasting a lot of money figuring out that the only option is to re-write (I used to think that meant total loss, but I realize these days that you don't destroy the intrinsic result of iterative development at the level of external functionality).

Personally, I woulnd't mind having someone like that on the team, because in a crunch, they might do something that nobody else thinks of.

On the other hand, be your own person and decide for yourself what the answer to your question is, because the only thing that's for sure is that nobody has it figured out when it comes to building software. It's one of the things that makes it an interesting field...

  • I agree, unless its an ad-hoc solution that never need to be touched again, having some sort of pattern is important because its not just about "making it work" someone will eventually need to look "under the hood" and make sense of it Commented Jun 11, 2011 at 18:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.