Cowboy coding: Difference between revisions

Revision as of 18:54, 13 July 2007

Latest revision as of 04:24, 13 August 2025

(231 intermediate revisions by more than 100 users not shown)

Line 1:

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

{{Not verified|date=June 2007}}

{{multiple issues|

{{Notability|Neologisms|date=June 2007}}

{{procon|date=July 2013}}

'''Cowboy coding''' is an extremely common, popular and empirically proven form of [[software development]] method without an actual defined method – team members do whatever they feel is right, typically yielding excellent customer satisfaction. Typical cowboy coding will involve no initial definition of the purpose or scope of the project, no formal description of the project, and will often involve one programmer. It is characterised by a single programmer jumping into the writing of the software often working from his own idea of what the software should do. It is often characterised by a lack of any documentation for either the requirements of the project or the design of the software overall.

{{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. Typically, little to no coordination exists with other developers or stakeholders.

As with all methodologies, the skill and experience of the developer define the degree of success and/or abuse of such activity. Controls and/or checks and balances systematically embedded within a process offer stronger levels of accountability for the developer.

A cowboy coder can be a lone developer or part of a group of developers working with minimal process or discipline.<ref>{{cite web |last1=Scott |first1=Welker |title=cowboy coding |url=https://searchsoftwarequality.techtarget.com/definition/cowboy-coding |website=searchsoftwarequality |publisher=TechTarget |access-date=2 March 2022}}</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}}

Both lightweight and heavy weighted methodologies of today still lead to this breakdown as the developer attempts to operate within social/political environments within organizations. The probability of this breakdown can be directly correlated to the degree of processes inhibiting the developer from deviating from the organization standard, however at the potential cost of efficiency.

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

'''Advantages:'''

'''==Disadvantages:''' ==

* Empirically proven.

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:

* Typically yields excellent customer satisfaction.

* Well known and common-place. Developers need no training to quickly ramp up and be productive.

* Facillitates rapid project completion.

* Readily co-exists with many other standards: Six Sigma, CMMI, IS0 9001, etc.

* Allows for quick solutions for small problems. Often a problem is small enough and well understood enough that documentation and planning are overkill. Typically when the job is going to take a day or two, and involve only a single developer.

* Can allow a 'spike' to see if a programming idea is valid before embarking on a larger project that depends on the idea. A spike is where you write a small proof of concept application to prove that a method is valid. These applications generally do not form part of a real finished application.

===Lack of release structure===

'''Disadvantages:'''

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" 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===

* Lacks a clear scope and vision. The project sponsors will have no clear idea that their objectives have been communicated with the developer.

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.

* Only suitable for small projects. Complex projects may progress rapidly in the beginning, but then become bogged down as the developer finds adding more functionality to the codebase increasingly difficult.

* Tends to produce poorer quality software. With no [[code review]], [[pair programming]], [[unit testing]], release testing or other quality mechanism cowboy coding tends more to produce buggy software.

* Does not scale well. If there is more than one programmer there needs to be some mechanism for them to organise the development. At this point even small teams will document and organise the project in some form.

* Lack of [[version control]]. Cowboy coding will often ignore other industry best practices, such as using a version control system. Since cowboy coders often work alone they see no point in the overhead of a version control system.

* Is a huge risk to the business. A lone cowboy coder could leave a project, and no one else might understand his/her code well enough to continue development.

This can result in underestimating time required for learning, causing delays in the development process. Inexperience might also lead to disregard of accepted [[Standard operating procedure#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===

'''Other Software Development Methods that are commonly confused with Cowboy coding:'''

Custom software applications, even when using a proven development cycle, can experience problems with the client concerning requirements. Cowboy coding can accentuate this problem by not scaling the requirements to a reasonable timeline, and might result in unused or unusable components being created before the project is finished. Similarly, projects with less tangible clients (often experimental projects, see [[independent game development]]) could begin with code and never a formal analysis of the design requirements. Lack of design analysis could lead to incorrect or insufficient technology choices, possibly requiring the developer to [[porting|port]] or rewrite their software in order for the project to be completed.

===Incompleteness===

Cowboy coding, often used as a derogatory term, has been confused with other software development methodologies which have solved the issues surrounding cowboy coding. [[Extreme Programming]] for example also does not emphasize documentation. However Extreme Programming does use methods to document user requirements and guide the software development team. It also addresses code quality through unit tests and peer review, and is thus quite different.

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:'''==

[[agile software development|Agile development]]'s frequent reevaluation of plans, emphasis on face-to-face communication, and relatively sparse use of documents sometimes cause people to confuse it with cowboy coding. Agile teams, however, do follow defined (and often very disciplined and rigorous) processes, something that distinguishes agile approaches from cowboy coding.

* 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 project could come to fruition which otherwise wouldn't have.<ref>K, Alex. [https://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==

* [[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

* [[Self-employment]]

* [[Indie game development]]

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

==References==

<references/>

==External links==

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

* [http://c2.com/cgi/wiki?CowboyCoding Cowboy Coding] definition at [[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]]