Cowboy coding: Difference between revisions

Revision as of 05:11, 27 June 2021

Latest revision as of 04:24, 13 August 2025

(7 intermediate revisions by 6 users not shown)

Line 2:

{{multiple issues|

{{procon|date=July 2013}}

{{POV|date=July 2013}}

{{refimprove|date=January 2011}}

{{original research|date=January 2011}}

Line 8 ⟶ 7:

}}

{{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]].

Line 23:

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, 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 34:

* 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 well 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 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, May 18, 2006</ref>

==See also==