Cowboy coding: Difference between revisions

Revision as of 18:54, 13 July 2007

Revision as of 18:58, 13 July 2007

Line 16:

* 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 23 ⟶ 24:

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