Talk:Cowboy coding

This article was nominated for deletion. Please review the prior discussions if you are considering re-nomination: keep, 1 February 2016, see discussion. keep, 24 July 2015, see discussion.

This article is rated Start-class on Wikipedia's content assessment scale. It is of interest to the following WikiProjects:

Computing: Software Low‑importance This article is within the scope of WikiProject Computing, a collaborative effort to improve the coverage of computers, computing, and information technology on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.ComputingWikipedia:WikiProject ComputingTemplate:WikiProject ComputingComputing Low This article has been rated as Low-importance on the project's importance scale. This article is supported by WikiProject Software (assessed as Low-importance).

Tip: Anchors are case-sensitive in most browsers. This article contains broken links to one or more target anchors: {{Section link|Cowboy|Negative associations}} The anchor (,Cowboy,) has been deleted by other users before. The anchors may have been removed, renamed, or are no longer valid. Please fix them by following the link above, checking the page history of the target pages, or updating the links. Remove this template after the problem is fixed | Report an error

I have cleaned what seemed to be the most biased or uncertain affirmations. Nontheless, this entry still lacks credible sources.

This article has a strong bias against its subject and reads like FUD spread by people trying to sell more programming-methodology books. It paints in very broad strokes, with pointless phrases like, "typical cowboy coding" - as meaningful as saying, "typical non-blonde", since cowboy coding is mainly defined by what it's *not*. Other gems include, "no initial definition of the purpose or scope of the project". So the "typical" cowboy programmer just sits down at the computer and starts typing code without knowing what the program is supposed to do? Please. The article needs a more balanced view than: "You can't write good software if you don't use a strongly defined & enforced programming-methodology. (So go buy more 'Agile' books)."

This article is one big agile advertisement. 216.138.75.50 19:50, 5 March 2007 (UTC)[reply]

I'm not a fan of cowboy coding but the bit about ignoring source control is total nonsense. 70.55.45.75 01:25, 24 March 2007 (UTC)[reply]

Yes it seams quite negative, the article. The disadvantages are listed first in headlines, instead of a bullet list like in the advantages. Essentially i live in a cowboy company, no one needs to tell the seniors what to do, their expert in their fields. The workload is high but reasonable for all, (*ea we don't do ever lasting web projects, we create and finish programs within ranging from in between 1 week and a half year, rarely it takes longer (industrial automation has finish dates, unlike common web development). The best part of it, no one is stressed cause unlike scrum where young devs overestimate and plan their burnouts. To me a cowboy is a senior knowing it all. Though younger people fear their knowledge and skillset often. 91.132.240.163 (talk) 06:43, 10 July 2024 (UTC)[reply]

I was just looking for the cowboy coding slogan: "Ready! Fire! Aim!"

The advantages and disadvantages contain contradictory items, for example "cowboy coding is scalable" vs "cowboy coding doesn't scale well" (the latter stance being the better argumented one, IMHO). I'll fix the article when I have time. Uttumuttu 01:45, 27 July 2007 (UTC)[reply]

The most contentious claim on this page is that cowboy coding is "empirically proven". I have no agile programming axe to grind, but have met my fair share of cowboy programmers and the only thing their code is proven to do is to apparently work for a while, as it stores up bugs for competent programmers to fix, and hopefully doesn't actually kill the business it's supposed to serve meanwhile. Cow133 09:56, 5 August 2007 (UTC)[reply]

"Stodgy corporate types might see this as a disadvantage, but recent university research has confirmed otherwise." There is no link to the "recent university research". I also imagine this website was not a place for original research in the first place.

Could we clean out the line above entirely? It seems biased at best, unverifiable at worst. Aschrock 22:40, 23 August 2007 (UTC)[reply]

The term "Cowboy coding" carries heavy negative connotations. This isn't a "methodology" so much as an insult. The entry should not be "scrubbed" to remove bias, it should be documented as a derogatory label for an anti-pattern, and differentiated from a less biased name for a related methodology (such as "Code_and_fix" as labeled by Steve McConnell in Rapid Development)--which by the way is an article in serious need of help as well. Stevelle 22:41, 23 October 2007 (UTC)[reply]

Is it really an anti pattern, i think scrum is an anti pattern, both are styles.

and you can be against it, but so can people be against scrum (people planning burnouts).

It's just development without the micro managment overhead IMO 91.132.240.163 (talk) 06:47, 10 July 2024 (UTC)[reply]

The entire article is just a huge, biased procon list. The best solution I can think of would be to merge it somewhere, into an article in better shape. MopSeeker (talk) 13:25, 30 July 2013 (UTC)[reply]

Where are the references for the "Advantages" and "Disadvantages" sections? Who has "characterized", "described" and so forth? Classic weasel-wording. Reading this article I get the strong impression that someone is setting up a straw man. mdf 21:33, 13 November 2007 (UTC)[reply]

Inexperienced developers? This section should go completely in my view as inexperienced developers is a cause of and not an effect of cowboy coding —Preceding unsigned comment added by 168.87.3.33 (talk) 15:10, 1 September 2010 (UTC)[reply]

As unlikely as this article reads, it's very precise and important to recognize. Most small companies do implement Cowboy Coding - usually under the misnomer of Rapid Application Development. It's risky, but can also be profitable for small companies by keeping the overhead down. It should be recognized, especially when a smaller company begins to grow and try to apply more advanced development cycles.

Most companies would be reluctant to reveal this method to their clients - it's far from impressive. And as the nature of this development method centers around a lack of documentation, it will be challenging to find documentation on the topic, I think. Perhaps a proper survey would accommodate this. --Fabricari (talk) 15:55, 27 November 2007 (UTC)[reply]

You make some good points. But until there are sufficiently reliable and respected sources outside Wikipedia that can be cited, it is not encyclopedia-worthy. Wikipedia has aNo Original Research policy. Do your research, publish a book, or a paper in a scholarly journal, and I'll gladly cite it to resurrect this article. Until then, I think whatever need there might be for an article for unstructured coding would best be served by adding a section to Rapid Application Development saying that it is sometimes (mis?)used to cover for a lack of any development methodology.--GlenPeterson (talk) 15:35, 1 February 2016 (UTC)[reply]

You did not add the AfD correctly. There are not scholarly journals on the subject, and that's the the threshold for notability. Walter Görlitz (talk) 15:53, 1 February 2016 (UTC)[reply]

I agree with you, smaller companies also have serious deadlines for multiple projects.

unlike those large companies build around one large project, they have to deliver.

To them overhead of scrum paperwork that needs to be agreed upon by a scrum owner a next level manager CEO etc.

Doesn't deliver the projects any sooner. It's only planning insight you get in return which still can change at every scrum run, and longer off work time. (on the positive side scrum learns some devs to talk humanly).

And yet we see the raising of new products at such companies at alarming rates (ea new machine logic etc).

I've created software with 3 cowboys, which was just 1 peace of the many projects we did.

I left company, the product went to another company, that company wanted me, and they had 30 developers..

I refused, as I was a bit done with the long travel times. but 3 vs 30, and yes they did it all, scrum, test driven development. though started the product with first me and eventually 3 people in 2 month's we had the hardware and software running furfilling the design goals. So yes the other company milked the product to make more money of it, though they were not the best people, i've seen the questions to me when they asked me to work for them. 91.132.240.163 (talk) 06:59, 10 July 2024 (UTC)[reply]

I fear some users above have taken this article personally. Those comments seem so strange to me, as I think it is hard to get emotional about "software design concepts". I read the article, and then this talk page. The talk page surprised me. The article certainly does not seem like an advertizement (maybe it's been updated). I encourage editors to be "detatched" from this subject, and beware of your edits if you "self-identify" as a cowboy coder. I have fallen into this anti-pattern before. It does have a nice property: it makes you feel good at the time. Ace Frahm (talk) 03:57, 16 December 2007 (UTC)[reply]

Read this to the bottom and perhaps find a way to improve this article, there can be good cowboy and bad cowboy development. I realize I do it in this way, I code it once, find the bugs then recode and refactor it as to completely avoid those problems. Its fast, its easy and it works. —Preceding unsigned comment added by 198.108.192.90 (talk) 23:42, 15 October 2008 (UTC)[reply]

Are there actually people out there proponing Cowboy Programming as the right way to do things? All comments I see here, reflects that it is kind of an inofficial method, but it is called something else, like RAD or so, and some external links reflect over the contents in this article. Isn't Cowboy Programming just a derogatory phrase over a set of less organised and less formalised methods generally perceived as something else? Then the article should treat the topic Cowboy Programming not as a real method, but as a "state of the art" real life situation, kind of, when diverse methods fail. ... said: Rursus (bork²) 20:20, 1 July 2009 (UTC)[reply]

I'm not sure if you'd call me a "proponent", but I can say a few things here. Number one, this line has a silly looking error, and reads funny (grammar):

"Cowboy coding is common at the hobbyist- or student-level ***where developers may initially unfamiliar*** with the technologies, such as the build tools, that the project requires."

be? :-/

Note my triple stars for the elegant "syntax highlight". The article definitely needs some work, and I agree with the person who also finds it silly that people get emotionally stirred about software design concepts. My personal opinion of 'cowboy coding' is that the term is racist, and we should lobby to change it! No, just kidding, haha... But I think it certainly is a valid concept under CERTAIN circumstances. Not that my opinion really amounts to jack, but just listen... First case: Student needs to write a simple calculator program in BASIC. Why should the student spend 6 months planning and prototyping under stringent design guidelines when he/she can finish the project and learn how to improve his/her actual knowledge of the language/syntax? Case 2: Very small, open source project or very small business wants to make a public application prototype to test the viability of certain designs. Once again, why introduce unnecessary overhead? Case 3: This is the one time you could say I use 'cowboy' code. I'm obsessive, and think about programming all the time and what sorts of new things I can create or introduce into existing architecture. I'm always dreaming up concepts of the most efficient ways to represent real-world scenarios on a CPU. For a slightly silly example, let's say I want to create a program which accurately models the life of a squirrel and its behaviors. I think of different ideas, and I have to try some out in real code to organize my thoughts. I instantly go sit down and just start writing code and doing simple, un-choreographed tests. I might think of ways to enumerate the squirrels behaviors with bit-wise operations, or how to serialize information about the squirrel for transfer in a TCP client/server relationship. I jot down what seems to work (and doesn't) in my messy sribbly notebooks. All valuable information for a structured development cycle. Before all the "red tape" is introduced, I've got some unofficial, personal notes and ideas to bring to the table and speed things up. After that, I move into TDD and get highly structured in proving my concepts. From there on out, I pursue whatever design concepts are the most valid for the project at hand.

So yes, I think we should tone down the emotions, and avoid bashing on things that other people like. If it works for them, it's their "bull to ride". No one is asking you to grab the reigns, "cowboy". :) Some of you might be able to appreciate a little (un?)organized chaos before a project becomes extremely rigid and structured. It does feel good to have a little bit of creative freedom and fluidity.

Thanks for your time!

P.S.- Duh, I did not mistake this as some forum. I think my post pertains to the article due to the debate about what this concept truly is... ;) —Preceding unsigned comment added by 67.142.163.20 (talk) 14:05, 7 November 2009 (UTC)[reply]

"Agile" development works well with brown-field projects with short release cycles but where there are large amounts of work to be done, it works well to allow the development stage to be a bit more "cowboy", as long as you have some code reviews in place and communication between developers, in particular to use of common tools and how their work interacts with each other. —Preceding unsigned comment added by 132.185.237.211 (talk) 08:52, 26 July 2010 (UTC)[reply]

This whole entry seems overdone. Having used the "cowboy" term over the years, I can guarantee that there was never any connotation other than negative. I can't think of a single professional software developer who would use it in any other than a derogatory way. May I suggest this would be a better entry if it were "dumbed way down" to the effect:

"A jargon term used among professional software developers, referring disparagingly to an undisciplined approach to software development. The term is subjective, relative to the speaker's understanding of some more structured/disciplined (and by implication, superior) approach. As increasing software complexity drove early developers to adopt more disciplined practices, the term came into usage as a reference to "the old way", especially as applied to resistance to the new disciplines.

"The term has reference to the solitary, fiercely independent, and often stubborn cowboys of the American West in the 1800's."

RobR (talk) 21:11, 4 March 2010 (UTC)[reply]

As a freelance mercenary, i am worked in several companies under different style of management, Cowboy is bad, it is not so easy to planning a project but, other styles are even worst, ITIL, PMP, Agile... all of them are not perfect and depend in the team. The main advantage of Cowboy is that is so quick.

In resume, if the team is poor, then it will fail, no matter the planning or bureaucracy involved on it, otherwise, if the team is well formed (clockwork) then they don't need any extra stuff such create useless diagram or spend time in useless meetings, they can do the work quick and efficiently. --190.22.80.151 (talk) 15:58, 24 July 2011 (UTC)--190.22.80.151 (talk) 15:58, 24 July 2011 (UTC)[reply]

Actually, cowboy is completely unorganized and as such requires more rework than the others you mention. I will never work for a cowboy shop. --Walter Görlitz (talk) 20:02, 24 July 2011 (UTC)[reply]

just tagged this with "not a worldwide view" because this it seems is how people in the usa use the term cowboy-something.

someone from the uk (for instance) who uses the term means "someone who produces dodgy work".

The Elves Of Dunsimore (talk) 08:49, 28 January 2011 (UTC)[reply]

Is this an analogy? If so what characteristics do cowboys and cowboy coders have in common?

199.166.186.1 (talk) 16:48, 14 March 2013 (UTC)[reply]

Not an analogy.

The three paragraphs in the lede explain it fairly well. Walter Görlitz (talk) 17:18, 14 March 2013 (UTC)[reply]

Seriously? Wikipedia is going to benefit from an explanation of what 'Cowboy Coding' is?

SERIOUSLY?

Whoever proposed this waste of bandwidth should be kicked out of his mom's basement. Recommend for deletion — Preceding unsigned comment added by 130.76.32.78 (talk) 16:19, 1 August 2013 (UTC)[reply]

Northeastern US residents sometimes use the term "Cowboy" derogatorily to mean reckless or irresponsible. Sticking the word "Cowboy" in front of the word "Coding" doesn't make it a software development philosophy. It just means the same thing as "Cowboy-anything" but applied to code. This article should be deleted. --GlenPeterson (talk) 22:59, 23 July 2015 (UTC)[reply]

Well, the way this articles phrases it, this term indicates that the programmer is reckless and irresponsible, mostly due its inexperience. --200.225.221.113 (talk) 14:45, 11 August 2015 (UTC)[reply]

I think this page should be saved. I learned much from it. Michael Stueben (talk) 16:25, 12 December 2015 (UTC)[reply]

I just leave two links here: Software development process and Software development. Ushkin N (talk) 08:50, 23 May 2016 (UTC)[reply]

new car sign ** COWLADY CODING — Preceding unsigned comment added by 2600:1700:A350:E550:4CCE:E29D:A50F:6515 (talk) 18:40, 17 September 2019 (UTC)[reply]

I think the topic is valid, but it is a fictional mode of programming (a red herring) invented by Agile proponents, in order to explain the advantages of the methods that Agile adherents propone. Cowboy coding was never a concept before the Agile proponents invented it, although aspects of it could be common bad practices that Agile tries to get rid of. Perhaps the article should be part of Agile software development? Rursus dixit. (^mbork³!) 08:39, 21 October 2022 (UTC)[reply]

I was taught, and have proceeded to teach this term in regards to code that is generated outside a formal software development process. It is a tried and true concept, possibly born coloquially, but far-reaching and reaching further. I feel this article in its current state is excellent in describing the concept, especially noting that it is a derogatory term. I also question the need of a PRO/Con list, and definitely not one that doesn't list any of the Cons, of which there should be many. 2601:C2:30:104C:B93C:DE0F:E0A6:7129 (talk) 00:39, 11 February 2023 (UTC)[reply]

Yeah this article was exactly what I needed to describe something I have frequently encountered. Mathiastck (talk) 22:17, 22 July 2024 (UTC)[reply]