Extreme programming

[2][3][4] The methodology takes its name from the idea that the beneficial elements of traditional software engineering practices are taken to "extreme" levels.

Kent Beck developed extreme programming during his work on the Chrysler Comprehensive Compensation System (C3) payroll project.

Chrysler brought in Kent Beck,[5] a prominent Smalltalk practitioner, to do performance tuning on the system, but his role expanded as he noted several problems with the development process.

He took this opportunity to propose and implement some changes in development practices - based on his work with his frequent collaborator, Ward Cunningham.

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).

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.

XP generated significant interest among software communities in the late 1990s and early 2000s, seeing adoption in a number of environments radically different from its origins.

Such a more relaxed schedule could avoid people feeling rushed to generate artificial stubs just to pass the end-of-day testing.

XP attempts to reduce the cost of changes in requirements by having multiple short development cycles, rather than a long one.

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 methodology.

XP describes four basic activities that are performed within the software development process: coding, testing, listening, and designing.

The advocates of XP argue that the only truly important product of the system development process is code – software instructions that a computer can interpret.

System-wide integration testing was encouraged, initially, as a daily end-of-day activity, for early detection of incompatible interfaces, to reconnect before the separate sections diverged widely from coherent functionality.

[citation needed] Extreme programming initially recognized four values in 1999: communication, simplicity, feedback, and courage.

Extreme programming techniques can be viewed as methods for rapidly building and disseminating institutional knowledge among members of a development team.

To this end, extreme programming favors simple designs, common metaphors, collaboration of users and programmers, frequent verbal communication, and feedback.

The difference between this approach and more conventional system development methods is the focus on designing and coding for the needs of today instead of those of tomorrow, next week, or next month.

Coding and designing for uncertain future requirements implies the risk of spending resources on something that might not be needed, while perhaps delaying crucial features.

Flaws in the system are easily communicated by writing a unit test that proves a certain piece of code will break.

Programmers should never commit changes that break compilation, that make existing unit-tests fail, or that otherwise delay the work of their peers.

Members respect their own work by always striving for high quality and seeking for the best design for the solution at hand through refactoring.

Planning, managing and designing are called out explicitly to counter claims that XP doesn't support those activities.

Here are some of the rules (incomplete): Coding Testing The principles that form the basis of XP are based on the values just described and are intended to foster decisions in a system development project.

[5] Proponents of extreme programming claim that by having the on-site customer[5] request changes informally, the process becomes flexible, and saves the cost of formal overhead.

Critics of XP claim this can lead to costly rework and project scope creep beyond what was previously agreed or funded.

[citation needed] Change-control boards are a sign that there are potential conflicts in project objectives and constraints between multiple users.

The book also makes other criticisms, and it draws a likeness of XP's "collective ownership" model to socialism in a negative manner.

JPMorgan Chase & Co. tried combining XP with the computer programming methods of capability maturity model integration (CMMI), and Six Sigma.