Cowboy coding: Difference between revisions

Revision as of 00:33, 11 January 2006

Revision as of 00:50, 3 February 2006

Line 1:

'''Cowboy coding''' is a form of [[software development]] method without an actual defined method - team members do whatever they feel is right. [[agileTypical softwarecowboy development|Agilecoding development]]'swill frequentinvolve reevaluationno initial definition of plansthe purpose or scope of the project, emphasisno onformal face-to-facedescription communicationof the project, and relativelywill sparseoften useinvolve one programmer. It is characterised by a single programmer jumping into the writing of documentsthe sometimessoftware causeoften peopleworking tofrom confusehis itown withidea cowboyof coding.what Agilethe teams,software however,should do. followIt definedis (andalso oftencharacterised veryby disciplineda andlack rigorous)of processes,any somethingdocumentation thatfor distinguisheseither agilethe approachesrequirements fromof cowboythe codingproject or the design of the software overall.

Disadvantages:

- 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's good enough, and consequently it becomes difficult or impossible to maintain.

- Only suitable for small projects. Projects that require a high degree of complexity will begin by showing fast progress, but then become bogged down as the the developer finds adding more functionality to the codebase increasingly difficult.

- Poor quality software. With no code review, peer programming, unit testing, release testing or other quality mechanism cowboy coding tends to produce buggy software.

Advantages:

- 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:

Cowboy coding; often used as a diminutive term, has been confused with other software development methodologies which have solved the issues surrounding cowboy coding. Extreme Programming for example also does not emphasise 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.

{{soft-eng-stub}}