The Full Wiki

Cowboy coding: Wikis


Note: Many of our articles have direct quotes from sources you can cite, within the Wikipedia article! This article doesn't yet, but we're working on it! See more info or our list of citable articles.


From Wikipedia, the free encyclopedia

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

A cowboy coder can be a lone developer or part of a group of developers with either no external management or management that controls only non-development aspects of the project, such as its nature, scope, and feature set (the "what", but not the "how").

Cowboy coding can have positive or 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 derogatory term by supporters of software development methodologies, such as Agile. However, the term has been reclaimed to some extent by those practicing within the community.


Disadvantages of Cowboy Coding

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[1]. Software projects with these attributes may exhibit:

  • Lack of release structure

The project may lack a feasibility study, estimation, or implementation planning may 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.

  • Inexperienced developers

Cowboy coding is common at the hobbyist or student level where developers may initially be unfamiliar with the technologies, such as the build tools, that the 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 standards, making the project source difficult to read or causing conflicts between the 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 port or rewrite their software in order for the project to be completed.

  • Incompleteness

Many software development models, such as SCRUM, use an incremental approach which stresses functional prototypes at each phase. Non-managed projects may have few unit tests or working iterations, leaving an incomplete project unusable.

Advantages of Cowboy Coding

  • Developers maintain a freeform working environment that may encourage experimentation, learning, and free distribution of results.
  • It allows developers to cross architectural &/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.
  • Independent developers can begin with cowboy coding techniques before later selling them to commercial use or creating community-supported projects.
  • Small projects may be burdened by heavy software management methodologies; cowboy coding removes this burden.
  • By coding in their own time, a hobby project may come to fruition which otherwise wouldn't have[2].

Examples of cowboy coding

External links


  1. ^ Hughes, Bob and Cotterell, Mike (2006). Software Project Management, pp.283-289. McGraw Hill Education, Berkshire. ISBN 007719899
  2. ^ K, Alex. Google's "20 percent time" in action, Official Google Blog, 2006-5-18


Got something to say? Make a comment.
Your name
Your email address