Cowboy coding: Difference between revisions

Content deleted Content added
Line 10:
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 be 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.