Cowboy coding: Difference between revisions

Revision as of 16:27, 12 February 2007

Revision as of 04:24, 14 February 2007

Line 1:

{{not verified}}

'''Cowboy coding''' is a form of [[software development]] method 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 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 alsooften characterised by a lack of any documentation for either the requirements of the project or the design of the software overall.

As with all methodologies, the skill and experience of the user(s) 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 of the user(s). It is the degradation of well intended procedures which leads to activities often defined as Cowboy coding.

Both lightweight and heavy weighted methodologies of today still lead to this breakdown as the user(s) 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 user(s) from deviating from the organization standard, however at the potential cost of efficiency.

Line 11:

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

* Encourages a lack of visibility in the code. Poor coding can be hidden, as there is nobody to review it. This leads to developers who believe that as long as the code works, it is good enough, and it consequently becomes difficult to maintain.

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

* PoorA tendency to produice 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 practises, 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.

Line 22 ⟶ 21:

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

* Can be used by students to learn more about programming in general, and to explore problem domains. Generally businesses will not be willing to pay for this kind of exercise in a commercial setting.

'''Other Similar Methods:'''