Cowboy coding: Difference between revisions

Revision as of 16:11, 1 February 2016

Latest revision as of 04:24, 13 August 2025

(45 intermediate revisions by 32 users not shown)

Line 1:

{{Short description|Derogatory term in software development}}

<!-- Please do not remove or change this AfD message until the issue is settled -->

{{AfDM|page=Cowboy coding (2nd nomination)|year=2016|month=February|day=1|substed=yes|origtag=afdx}}

<!-- End of AfD message, feel free to edit beyond this point -->

{{multiple issues|

{{procon|date=July 2013}}

{{POV|date=July 2013}}

{{refimprove|date=January 2011}}

{{original research|date=January 2011}}

{{globalize|date=January 2011}}

}}

{{Use mdy dates|date=February 2016}}

'''Cowboy coding''' is [[software development]] where programmers have [[autonomy]] over the development process. This includes control of the project's schedule, languages, algorithms, tools, frameworks and coding style.

'''Cowboy coding''' is [[software development]] where programmers have [[autonomy]] over the development process. This includes control of the project's schedule, languages, algorithms, tools, frameworks and coding style. Typically, little to no coordination exists with other developers or stakeholders.

A cowboy coder can be a lone developer or part of a group of developers working with minimal process or discipline.{{Citation needed|date=January 2011}} Usually it occurs when there is little participation by business users, or fanned by management that controls only non-development aspects of the project, such as the broad targets, timelines, scope, and visuals (the "what", but not the "how").{{Citation needed|date=January 2011}}

A cowboy coder can be a lone developer or part of a group of developers working with minimal process or discipline.<ref>{{Citationcite web needed|last1=Scott |first1=Welker |title=cowboy coding |url=https://searchsoftwarequality.techtarget.com/definition/cowboy-coding |website=searchsoftwarequality |publisher=TechTarget |access-date=January2 March 20112022}}</ref> Usually it occurs when there is little participation by business users, or fanned by management that controls only non-development aspects of the project, such as the broad targets, timelines, scope, and visuals (the "what", but not the "how").{{Citation needed|date=January 2011}}

"Cowboy coding" commonly sees usage as a [[pejorative|derogatory]] term when contrasted with more structured [[software development methodology|software development methodologies]].

==Disadvantages ==

In cowboy coding, the lack of formal [[software project management]] methodologies may be indicative (though not necessarily) of a project's small size or experimental nature.<ref>Hughes, Bob and Cotterell, Mike (2006). ''Software Project Management'', pp.283-289. McGraw Hill Education, Berkshire. {{ISBN |0-07-710989-9}}</ref> Software projects with these attributes may exhibit:

===Lack of release structure===

Lack of [[estimation (project management)|estimation]] or implementation planning might cause a project to be delayed. Sudden deadlines or pushes to release software may encourage the use of [["quick and dirty]] or [[code and fix]]" techniques that will require further attention later.<ref>{{cite web |url=http://www.stickyminds.com/sites/default/files/presentation/file/2013/09BSOFR_W7.pdf |title=In Defense of Waterfall: Deconstructing the Agile Manifesto |accessdate=February 1, 2016}}</ref>

===Inexperienced developers===

Cowboy coding can be common at the hobbyist or student level where developers might initially be unfamiliar with the technologies, such as testing, version control and/or build tools, usually more than just the basic coding a software project requires.

This can result in underestimating time required for learning to be underestimated, causing delays in the development process. Inexperience might also lead to disregard of accepted [[Standard Operatingoperating Procedureprocedure#Information technology industry use|standards]], making the project source difficult to read or causing conflicts between the [[Semantics#Computer science|semantics]] of the language constructs and the result of their output.<ref>{{cite web|url=http://www.stickyminds.com/presentation/stareast-2000-confessions-recovering-coding-cowboy|title=StickyMinds - STAREAST 2000: Confessions of a (Recovering) Coding Cowboy|work=StickyMinds|accessdate=February 2, 2016}}</ref>

===Uncertain design requirements===

Line 30 ⟶ 29:

===Incompleteness===

Many software development models, such as [[Extreme Programming]], use an incremental approach which stresses that the software must be releasable at the end of each iteration. Non-managed projects may have few [[unit testing|unit tests]] or working iterations, leaving an incomplete project unusable. As such, agile methodologies have been compared to cowboy coding but agile has formal processes, procedures, measurement, project management and other oversight while cowboy coding has none of this.<ref>{{cite web| url=http://www.stickyminds.com/sites/default/files/article/file/2013/XUS22546409file1_0.doc |title=Exploring Agile Development | work=Pragmatic Software Newsletter |issue=March 2007}}</ref><ref>{{cite web|url=http://www.stickyminds.com/better-software-magazine/dont-just-break-software-make-software|title=StickyMinds - Don't Just Break Software. Make Software|work=StickyMinds|accessdate=February 2, 2016}}</ref>

==Advantages==

* Developers maintain a free-form working environment that may encourage experimentation, learning, and free distribution of results.

* It allows developers to cross architectural and/or tiered boundaries to resolve design limitations and defects.

* As discussing architectures, writing specifications and reviewing the code all take their time, a single developer (if sufficient) may well produce a working application faster by cowboy coding. Tasks like research or prototyping may not require the code quality more complex methods provide.

* Since coding can be done during the developer's free time, a hobby project could come to fruition which otherwise wouldn't have.<ref>K, Alex. [httphttps://googleblog.blogspot.com/2006/05/googles-20-percent-time-in-action.html "Google's '20 percent time' in action"], Official Google Blog, 2006-5-May 18, 2006</ref>

==See also==

* [[Hacker (programmer subculture)|Hacker]], a subculture that relies on the creativity of individual programmers

* [[Code monkey (disambiguation)|Code monkey]], a pejorative term for programmers who are employed to write simple or repetitive code

* [[Programming in the large and programming in the small]]

* [[Self-employment]]

* [[Indie game development]]

* {{Section link|Cowboy|Negative associations}}

==References==

Line 48:

==External links==

* [http://c2.com/cgi/wiki?CowboyCoder Cowboy Coder] definition at Wards[[Ward Cunningham|Ward's]] Wiki

* [http://c2.com/cgi/wiki?CowboyCoding Cowboy Coding] definition at Wards[[Ward Cunningham|Ward's]] Wiki

* [{{cite web|url=http://cowboyprogramming.com/2007/01/11/delving-into-cowboy-programming/ |title=Delving into Cowboy Programming]|archiveurl=https://web.archive.org/web/20190323115724/http://cowboyprogramming.com/2007/01/11/delving-into-cowboy-programming/|archivedate=2019-03-23}}

{{independent media}}

[[Category:Software development philosophies]]

[[Category:Computer programming folklore]]

[[Category:Software engineering folklore]]