Cowboy coding: Difference between revisions

Revision as of 12:16, 3 August 2007

Revision as of 18:58, 4 September 2007

Line 1:

{{Not verified|date=June 2007}}

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

'''Cowboy Coding''' is an extremely common, popular and empirically proven form ofa [[software development]] methodmethodology without an actual defined method – team members do whatever they feel is right. 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 characterisedcharacterized 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 characterisedcharacterized by a lack of any documentation for either the requirements of the project or the design of the software overall.

'''Cowboy Coding''' may constitute a software management [[Anti-pattern]] as it is a practice which appears initially to be advantageous, yet ultimately results in consequences that outweigh any advantages. In order to be comebecome a formally recognized [[Anti-pattern]] '''Cowboy Coding''' will require a documented [[Refactored Solution]].

Much more so than in other methodologies, the skill and experience of the developer define the degree of success. Controls and/or checks and balances are not embedded in the cowboy coding method. So there is little accountability for the developer.

Both lightweight and heavy weighted methodologies of today can 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.

'''Advantages:'''

* Empirically proven, unlike other "theoretical" or "ivory-tower" approaches.

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

* FacillitatesFacilitates rapid project completion.

* Extremely flexible and scalable.

* 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 [[version control]] (given its antiquated premises). "Code control just slows me down," says one advocate of Cowboy Coding, quoting another oft-cited guru. Stodgy corporate types might see this as a disadvantage, but recent university research has confirmed otherwise.

'''Disadvantages:'''

Line 24 ⟶ 18:

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

* Only suitable for very 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.

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

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

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.

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

[[Category:Software development philosophies]]