Utente:Marcobombe/Sandbox: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
←Pagina svuotata completamente |
Nessun oggetto della modifica |
||
Riga 1:
'''Cowboy coding''' is a term used to describe software development where the developers have [[autonomy]] over the development process. This includes control of the project's schedule, algorithms, tools, and coding style.
A cowboy coder can be a lone developer or part of a group of developers with either no external management or management that controls only non-development aspects of the project, such as its nature, scope, and feature set (the "what", but not the "how").
Cowboy coding can have positive or negative [[connotations]], depending on one's opinions on the role of management and formal process in software development; "cowboy coding" is often used as a [[pejorative|derogatory]] term by supporters of software development methodologies, such as [[Agile software development|Agile]]. However, the term has been [[reclaimed word|reclaimed]] to some extent by those practicing within the community.
== Disadvantages of Cowboy Coding ==
In cowboy coding, the lack of formal [[software project management]] methodologies may be indicative (though not necessarily) of a project's small size or experimental nature<ref>Hughes, Bob and Cotterell, Mike (2006). ''Software Project Management'', pp.283-289. McGraw Hill Education, Berkshire. ISBN 007719899</ref>. Software projects with these attributes may exhibit:
* Lack of release structure
The project may lack a [[feasibility study]], [[estimation (project management)|estimation]], or implementation planning may cause a project to be delayed. Sudden deadlines or pushes to release software may encourage the use of [[quick and dirty]] or [[code and fix]] techniques that will require further attention later.
* Inexperienced developers
Cowboy coding is common at the hobbyist- or student-level where developers may initially unfamiliar with the technologies, such as the [[build tool|build tools]], that the project requires. This can result in time required for learning to be underestimated, causing delays in the development process. Inexperience may also lead to disregard of accepted [[Standard_Operating_Procedure#Information_technology_industry_use|standards]], making the project source difficult to read or causing conflicts between the [[Semantics#Computer_science|semantics]] of the language constructs and the result of their output.
* Uncertain design requirements
Custom software applications, even when using a proven development cycle, can experience problems with the client concerning requirements. Cowboy coding can accentuate this problem by not scaling the requirements to a reasonable timeline, and may result in unused or unusable components being created before the project is finished. Similarly, projects with less tangible clients (often experimental projects, see [[independent game development]]) may begin with code and never a formal analysis of the design requirements. Lack of design analysis may lead to incorrect or insufficient technology choices, possibly requiring the developer to [[porting|port]] or rewrite their software in order for the project to be completed.
* Incompleteness
Many software development models, such as [[SCRUM]], use an incremental approach which stresses functional prototypes at each phase. Non-managed projects may have few [[unit testing|unit tests]] or working iterations, leaving an incomplete project unusable.
== Advantages of Cowboy Coding ==
* Developers maintain a [[Freeform art|freeform]] working environment that may encourage experimentation, learning, and free distribution of results.
* Without a development/designer framework, the programmer, as opposed to the project manager, is responsible for removing roadblocks. This may improve the speed of development.
* Independent developers can begin with cowboy coding techniques before later selling them to commercial use or creating community-supported projects.
* Small projects may be burdened by heavy software management methodologies; cowboy coding removes this burden.
* By coding in their own time, a hobby project may come to fruition which otherwise wouldn't have<ref>K, Alex. Google's "20 percent time" in action http://googleblog.blogspot.com/2006/05/googles-20-percent-time-in-action.html, Official Google Blog, 2006-5-18</ref>.
== References ==
<references/>
<!--
== Examples of cowboy coding ==
{{POV-section|date=September 2009}}
* [http://web.archive.org/web/20070717193315/http://siliconuser.com/?q=node/10 How Adobe's Photoshop Was Born]
* [http://httpd.apache.org/ABOUT_APACHE.html About Apache HTTP Server]
* [http://www.guardian.co.uk/technology/2007/jul/25/media.newmedia A brief history of Facebook]
* [[History of Google#Early_history|Early history of Google]]
* [http://www.pacifict.com/Story/ The Graphing Calculator Story]
* [http://netfiles.uiuc.edu/rhasan/linux/#New%20Baby%20in%20the%20Horizon History of Linux]
* [http://blogs.sun.com/TechDaysEvents/entry/the_mysql_story The MySQL Story]
* [http://folklore.org/StoryView.py?story=Switcher.txt Switcher: The Macintosh's first multi-tasking environment]
== External links ==
* [http://c2.com/cgi/wiki?CowboyCoder Cowboy Coder] definition at Wards Wiki
* [http://cowboyprogramming.com/2007/01/11/delving-into-cowboy-programming/ Delving into Cowboy Programming]
[[Category:Software development philosophies]] -->
| |||