Team programming: Difference between revisions

Content deleted Content added
Line 9:
== Modern trends: multiple programmers to one sub-task ==
 
Difficulties were experienced with these older methods, such as costs spiralling out of control as systems grew, and schedules failing to meet time-to-market targets,. These issues gave rise to techniques such as [[pair programming]], along with new systems lifecycle structures such as the [[Boehm spiral]]. ConceivedSpecification of these new approaches began in the early mid-[[1990s1980s]], and continues today. Many of these strategies involve multiple programmers working collaboratively on the ''same'' piece of [[source code]] as opposed to being ''individually'' responsible for individual tasks. ThisFor techniqueexample, in "pair programming", responsibility for the resulting product is frequentlyequally usedshared inbetween newertwo programmingprogrammers methodologieswho thatwork areon focusedtheir aroundassigned [[objectsub-oriented]]task programmingtogether. techniques,Benefits suchof asthis approach include the [[Rationalability Unifiedfor Process]]deficiencies in knowledge and [[Extremeability Programming]]in (acronymspecific "XP"),areas oftento inbe combinationcompensated withfor designby documentationthe methodsother suchprogrammer; asin addition, the [[Unifiedshared Modellingresponsibility Language]]is (UML)thought to increase incentives for meeting project deadlines and quality targets.
 
This technique is frequently used in newer programming methodologies that are focused around [[object-oriented]] programming techniques, such as the [[Rational Unified Process]] and [[Extreme Programming]] (acronym "XP"), often in combination with design documentation methods such as the [[Unified Modelling Language]] (UML).
In "pair programming", responsibility for the resulting product is equally shared between two programmers who work on their assigned sub-task together. Benefits of this approach include the ability for deficiencies in knowledge and ability in specific areas to be compensated for by the other programmer; in addition, the shared responsibility is thought to increase incentives for meeting project deadlines and quality targets.
 
== References ==