Cowboy coding: Difference between revisions

Revision as of 06:01, 5 February 2006

Revision as of 06:18, 5 February 2006

Line 6:

* 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[[pair programming]], [[unit testing]], release testing or other quality mechanism cowboy coding tends to produce buggy software.

* Doesn't 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.

'''Advantages:'''