Extreme programming: Difference between revisions

Revision as of 06:43, 10 May 2021

Latest revision as of 21:27, 3 August 2025

(45 intermediate revisions by 36 users not shown)

Line 3:

[[Image:Extreme Programming.svg|thumb|Planning and feedback loops in extreme programming]]

{{Software development process}}

'''Extreme programming''' ('''XP''') is a [[software development methodology]] which is intended to improve [[software quality]] and responsiveness to changing customer requirements. As a type of [[agile software development]],<ref name="Informatics85">"Human Centred Technology Workshop 2006 ", 2006, PDF, [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.465.2140&rep=rep1&type=pdf Human Centred Technology Workshop 2006 ]</ref><ref name=UPenn49/><ref name=USFCA601/> it advocates frequent "[[Software release life cycle|releases"]] in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted.

Other elements of extreme programming include: programming [[Pair programming|in pairs]] or doing extensive [[code review]], [[unit testing]] of all code, [[You aren't gonna need it|not programming features until they are actually needed]], a flat management structure, code simplicity and clarity, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.<ref name="UPenn49">[http://www.cis.upenn.edu/~matuszek/cit591-2003/Lectures/49-design-patterns.ppt UPenn-Lectures-design-patterns "Design Patterns and Refactoring", University of Pennsylvania, 2003] {{Webarchive|url=https://web.archive.org/web/20100802073814/http://www.cis.upenn.edu/%7Ematuszek/cit591-2003/Lectures/49-design-patterns.ppt |date=August 2, 2010 }}.</ref><ref name="USFCA601">[http://www.cs.usfca.edu/~parrt/course/601/lectures/xp.html USFCA-edu-601-lecture Extreme Programming].

</ref><ref name="MASD">{{cite web|url=http://agilemanifesto.org |title=Manifesto for Agile Software Development |year=2001 |publisher=Agilemanifesto.org |access-date=March 26, 2019}}</ref> The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels. As an example, [[code review]]s are considered a beneficial practice; taken to the extreme, code can be reviewed ''continuously'' (i.e., the practice of [[pair programming]]).

{{TOC limit|3}}

Line 12:

== History ==

[[Kent Beck]] developed extreme programming during his work on the [[Chrysler Comprehensive Compensation System]] (C3) payroll [[project]].<ref name=Cworld92/> Beck became the C3 [[Project management|project leader]] in March 1996. He began to refine the development methodology used in the project and wrote a book on the methodology (''Extreme Programming Explained'', published in October 1999).<ref name="Cworld92">[http://www.computerworld.com/article/2585634/app-development/extreme-programming.html Computerworld-appdev-92 "Extreme Programming", ''Computerworld'' (online), December 2001].

</ref> [[Chrysler]] cancelled the C3 project in February 2000, after seven years, when [[Daimler-Benz]] acquired the company.<ref name="SR">{{cite book | last1 = Rosenberg | first1 = Doug | last2 = Stephens | first2 = Matt | title = Extreme Programming Refactored: The Case Against XP | year = 2003 | publisher = Apress | isbn = 978-1-59059-096-6 | url-access = registration | url = https://archive.org/details/extremeprogrammi00matt }}</ref> [[Ward Cunningham]] was another major influence on XP.

</ref>

[[Chrysler]] cancelled the C3 project in February 2000, after seven years, when [[Daimler-Benz]] acquired the company.<ref name="SR">{{cite book | last1 = Rosenberg | first1 = Doug | last2 = Stephens | first2 = Matt | title = Extreme Programming Refactored: The Case Against XP | year = 2003 | publisher = Apress | isbn = 978-1-59059-096-6 | url-access = registration | url = https://archive.org/details/extremeprogrammi00matt }}</ref>

Many extreme-programming practices have been around for some time; the methodology takes "[[best practices]]" to extreme levels. For example, the "practice of test-first development, planning and writing tests before each micro-increment" was used as early as NASA's [[Project Mercury]], in the early 1960s.{{sfn| Larman | Basili|2003}} To shorten the total development time, some formal test documents (such as for [[acceptance testing]]) have been developed in parallel with (or shortly before) the software being ready for testing. A NASA independent test group can write the test procedures, based on formal requirements and logical limits, before programmers write the software and integrate it with the hardware. XP takes this concept to the extreme level, writing automated tests (sometimes inside software modules) which validate the operation of even small sections of software coding, rather than only testing the larger features.

=== Origins ===

Line 31 ⟶ 30:

Beck invited [[Ron Jeffries]] to the project to help develop and refine these methods. Jeffries thereafter acted as a coach to instill the practices as habits in the C3 team.

Information about the principles and practices behind XP disseminated to the wider world through discussions on the original [[wiki]], Cunningham's [[WikiWikiWeb]]. Various contributors discussed and expanded upon the ideas, and some spin-off methodologies resulted (see [[agile software development]]). Also, XP concepts have been explained{{by whom?|date=August 2019}}, for several years, using a [[hypertext]] system map on the XP website at http://www.extremeprogramming.org {{circa |1999}}.

Beck edited a series of books on XP, beginning with his own ''Extreme Programming Explained'' (1999, {{ISBN |0-201-61641-6}}), spreading his ideas to a much larger audience. Authors in the series went through various aspects attending XP and its practices. The series included a book critical of the practices.

Line 40 ⟶ 39:

The high discipline required by the original practices often went by the wayside, causing some of these practices, such as those thought too rigid, to be deprecated or reduced, or even left unfinished, on individual sites. For example, the practice of end-of-day [[integration test]]s for a particular project could be changed to an end-of-week schedule, or simply reduced to testing on mutually agreed dates. Such a more relaxed schedule could avoid people feeling rushed to generate artificial stubs just to pass the end-of-day testing. A less-rigid schedule allows, instead, the development of complex features over a period of several days.

Meanwhile, other agile-development practices have not stood still, and {{as of | 2019 | lc = on}} XP continues to evolve, assimilating more lessons from experiences in the field, to use other practices. In the second edition of ''Extreme Programming Explained'' (November 2004), five years after the first edition, Beck added more [[value (disambiguation) | values]] and practices and differentiated between primary and corollary practices.

== Concept ==

{{More citations needed section|date=February 2025}}

=== Goals ===

''Extreme Programming Explained'' describes extreme programming as a software-development discipline that organizes people to produce higher-quality software more productively.

Line 50 ⟶ 49:

In this doctrine, changes are a natural, inescapable and desirable aspect of software-development projects, and should be planned for, instead of attempting to define a stable set of requirements.

Extreme programming also introduces a number of basic values, principles and practices on top of the agile programming frameworkmethodology.

=== Activities ===

Line 63 ⟶ 62:

{{main|Test-driven development}}

Testing is central to extreme programming.<ref>{{cite book |title=Testing Extreme Programming|author1= Lisa Crispin |author2 = Tip House|isbn=9780321113559|date=2003|publisher= Addison-Wesley Professional }}</ref> Extreme programming's approach is that if a little testing can eliminate a few flaws, a lot of testing can eliminate many more flaws.

* [[Unit test]]s determine whether a given feature works as intended. Programmers write as many automated tests as they can think of that might "break" the code; if all tests run successfully, then the coding is complete. Every piece of code that is written is tested before moving on to the next feature.

* [[Acceptance test]]s verify that the requirements as understood by the programmers satisfy the customer's actual requirements.

Line 147 ⟶ 146:

* [[Planning game]]

* [[Test-driven development]]

* [[Extreme programming practices#Whole team|Whole team]]

=== Continuous process ===

Line 172 ⟶ 171:

* Requirements are defined incrementally, rather than trying to get them all in advance.

* Software developers are usually required to work in pairs.

* There is no [[Bigbig Designdesign Upup Frontfront]]. Most of the design activity takes place on the fly and incrementally, starting with <span id="SimplestThingThatCouldPossiblyWork"></span>"the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. Critics comparecharacterize this toas "[[debugging]] a system into appearance" and fear this will result in more re-design effort than only re-designing when requirements change.

* A [[customer representative]] is attached to the project. This role can become a single-point-of-failure for the project, and some people have found it to be a source of stress. Also, there is the danger of [[micro-management]] by a non-technical representative trying to dictate the use of technical software features and architecture.

Line 178 ⟶ 177:

=== Scalability ===

[[ThoughtWorksThoughtworks]] has claimed reasonable success on distributed XP projects with up to sixty people.{{Citation needed|date=August 2009}}

In 2004, industrial extreme programming (IXP)<ref>{{cite web|url=http://www.cutter.com/content-and-analysis/resource-centers/agile-project-management/sample-our-research/apmr0502.html|title=Industrial XP: Making XP Work in Large Organizations - Cutter Consortium|author=Cutter Consortium|work=cutter.com}}</ref> was introduced as an evolution of XP. It is intended to bring the ability to work in large and distributed teams. It now has 23 practices and flexible values.

=== Severability and responses ===

In 2003, [[Matt Stephens (author)|Matt Stephens]] and Doug Rosenberg published ''Extreme Programming Refactored: The Case Against XP'', which questioned the value of the XP process and suggested ways in which it could be improved.<ref name=SR/> This triggered a lengthy debate in articles, Internet newsgroups, and web-site chat areas. The core argument of the book is that XP's practices are interdependent but that few practical organizations are willing/able to adopt all the practices; therefore the entire process fails. The book also makes other criticisms, and it draws a likeness of XP's "collective ownership" model to socialism in a negative manner.

Certain aspects of XP have changed since the publication of ''Extreme Programming Refactored''; in particular, XP now accommodates modifications to the practices as long as the required objectives are still met. XP also uses increasingly generic terms for processes. Some argue that these changes invalidate previous criticisms; others claim that this is simply watering the process down.

Other authors have tried to reconcile XP with the older methodologies in order to form a unified methodology. Some of these XP sought to replace, such as the [[Waterfall model|waterfall methodology]]; example: ''Project Lifecycles: Waterfall'', [[Rapid Application Development]] (RAD), and All Thatetc. [[JPMorgan Chase & Co.]] tried combining XP with the computer programming methods of [[capability maturity model integration]] (CMMI), and [[Six Sigma]]. They found that the three systems reinforced each other well, leading to better development, and did not mutually contradict.<ref>[http://www.sei.cmu.edu/library/assets/jarvis-gristock.pdf Extreme Programming (XP) Six Sigma CMMI].</ref>

== Criticism ==

Extreme programming's initial buzz and controversial tenets, such as [[pair programming]] and [[continuous design]], have attracted particular criticisms, such as the ones coming from McBreen,<ref name="mcbreen">{{cite book| last = McBreen| first = P.| title = Questioning Extreme Programming| year = 2003| publisher = Addison-Wesley| ___location = Boston, MA| isbn = 978-0-201-84457-3 }}</ref> and Boehm and Turner,<ref name="boehm2004">{{cite book| author2 = R. Turner| last = Boehm| first = B.| author-link = Barry Boehm| title = Balancing Agility and Discipline: A Guide for the Perplexed| year = 2004| publisher = Addison-Wesley| ___location = Boston, MA| isbn = 978-0-321-18612-6 | author2-link = Richard Turner (computer scientist)}}</ref> Matt Stephens and Doug Rosenberg.<ref name="stephens2004">{{cite book| author2 = Doug Rosenberg| last = Stephens| first = Matt| author-link = Matt Stephens (author)| url=http://www.drdobbs.com/the-irony-of-extreme-programming/184405651 |title=The irony of extreme programming| work = Dr. Dobb's| year = 2004| publisher = Dr Dobbs journal| ___location = MA}}</ref> Many of the criticisms, however, are believed by Agile practitioners to be misunderstandings of agile development.<ref name="sdmagazine1811">[http://www.sdmagazine.com/documents/s=1811/sdm0112h/0112h.htm sdmagazine] {{webarchive|url=https://web.archive.org/web/20060316100811/http://www.sdmagazine.com/documents/s%3D1811/sdm0112h/0112h.htm |date=March 16, 2006 }}</ref>

In particular, extreme programming has been reviewed and critiqued by Matt Stephens's and Doug Rosenberg's ''Extreme Programming Refactored''.<ref name=SR/>

Criticisms include:

* a methodology is only as effective as the people involved, Agile does not solve this {{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* often used as a means to bleed money from customers through lack of defining a deliverable product {{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* lack of structure and necessary documentation {{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* only works with senior-level developers{{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* incorporates insufficient software design{{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* requires meetings at frequent intervals at enormous expense to customers{{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* requires too much cultural change to adopt{{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* can lead to more difficult contractual negotiations{{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* can be very inefficient; if the requirements for one area of code change through various iterations, the same programming may need to be done several times over. Whereas if a plan were there to be followed, a single area of code is expected to be written once.{{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* impossible to develop realistic estimates of work effort needed to provide a quote, because at the beginning of the project no one knows the entire scope/requirements{{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* can increase the risk of [[scope creep]] due to the lack of detailed requirements documentation{{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

* Agile is feature-driven; non-functional quality attributes are hard to represent as [[User story|user stories]].{{Citation needed|reason=Who has advanced this criticism?|date=May 2019}}

== See also ==

Line 227 ⟶ 212:

== Further reading ==

* [[Ken Auer]] and Roy Miller. ''Extreme Programming Applied: Playing To Win'', Addison–Wesley.

* {{cite book |chapter=Are Testers eXtinct? How Can Testers Contribute to XP Teams? |author=Ken Auer|author2=Ron Jeffries |author3=Jeff Canna |author4=Glen B. Alleman |author5=Lisa Crispin |author6=Janet Gregory |title=Extreme Programming and Agile Methods — XP/Agile Universe 2002|volume=2418|pages=287|publisher=Springer-Verlag |year=2002 |doi=10.1007/3-540-45672-4_50|isbn=978-3-540-44024-6|author2-link=Ron Jeffries|series=Lecture Notes in Computer Science|isbn=978-3-540-44024-6 }}

* [[Kent Beck]]: ''Extreme Programming Explained: Embrace Change'', Addison–Wesley. First edition, 1999. Second edition, with Cynthia Andres, 2004.

* [[Kent Beck]] and [[Martin Fowler (software engineer)|Martin Fowler]]: ''Planning Extreme Programming'', Addison–Wesley.

* [[Kent Beck]] and Cynthia Andres. ''Extreme Programming Explained: Embrace Change, Second Edition'', Addison–Wesley.

* [[Alistair Cockburn]]: ''Agile Software Development'', Addison–Wesley.

* [[Martin Fowler (software engineer)|Martin Fowler]]: ''Refactoring: Improving the Design of Existing Code''.With Kent Beck, Addison–WesleyJohn Brant, William Opdyke, and Don Roberts (1999). Addison-Wesley.

* [[Harvey Herela]] (2005). [https://archive.istoday/20070715005646/http://calla.ics.uci.edu/histories/ccc/ Case Study: The Chrysler Comprehensive Compensation System]. Galen Lab, U.C. Irvine.

* [[Jim Highsmith]]. ''Agile Software Development Ecosystems'', Addison–Wesley.

* [[Ron Jeffries]], Ann Anderson and Chet Hendrickson (2000), ''Extreme Programming Installed'', Addison–Wesley.

* {{cite journal |last1=Larman |first1=C. |author-link1=Craig Larman |last2=Basili |first2=V.R. |title=Iterative and incremental developments. a brief history |url=https://www.craiglarman.com/wiki/downloads/misc/history-of-iterative-larman-and-basili-ieee-computer.pdf |journal=Computer |date=June 2003 |volume=36 |issue=6 |pages=47–56 |doi=10.1109/MC.2003.1204375}}

* [[Craig Larman]] & V. Basili (2003). "Iterative and Incremental Development: A Brief History", Computer (IEEE Computer Society) 36 (6): 47–56.

* [[Matt Stephens (author)|Matt Stephens]] and Doug Rosenberg (2003). ''Extreme Programming Refactored: The Case Against XP'', Apress.

* Waldner, JB. (2008). "Nanocomputers and Swarm Intelligence". In: ISTE, 225–256.

Line 243 ⟶ 227:

{{Commons category|Extreme programming}}

{{Wikiquote}}

* [[WikiWikiWeb:ExtremeProgramming|Extreme Programming]]

* [http://www.extremeprogramming.org A gentle introduction]

* [http://www.IndustrialXP.org/ Industrial eXtreme Programming]