Cowboy coding: Difference between revisions

Revision as of 13:58, 30 September 2010

Revision as of 15:47, 1 November 2010

Line 1:

{{External links|date=January 2009}}

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

A cowboy coder can be a lone developer or part of a group of developers working with eitherminimal noprocess externalor managementdiscipline. 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 itsthe broad naturetargets, timelines, scope, and feature setvisuals (the "what", but not the "how").

Cowboy coding cantypically havehas positive ormore negative [[connotations]], depending on one's opinions on the role of management and formal process in software development; "cowboy coding" is often used as a [[pejorative|derogatory]] term by supporters of software development methodologies, such as [[Agile software development|Agile]]. However, the term has been [[reclaimed word|reclaimed]] to some extent by those practicing within the community.

== Disadvantages of Cowboy Coding ==

Line 14:

==== Inexperienced developers ====

Cowboy coding iscan be common at the hobbyist or student level where developers may initially be unfamiliar with the technologies, such as thetesting, version control and/or [[build tool]]s, thatusually more than just the basic coding a software project requires.

This can result in time required for learning to be underestimated, causing delays in the development process. Inexperience may 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.

==== Uncertain design requirements ====

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 may 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]]) may begin with code and never a formal analysis of the design requirements. Lack of design analysis may 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.

Line 21 ⟶ 23:

== Advantages of Cowboy Coding ==

* Developers maintain a freeformfree-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.

* Without a development/designer framework, the programmer, as opposed to the project manager, is responsible for removing roadblocks. This may improve the speed of development.