Cowboy coding: Difference between revisions

Revision as of 04:29, 14 February 2007

Revision as of 01:50, 21 February 2007

Line 10:

* 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 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 produiceproduce 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 practisespractices, 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.