Extreme programming

Extreme Programming or eXtreme Programming (hereinafter, XP) is a methodology for developing software engineering formulated by Kent Beck, author of the first book on the subject, Extreme Programming Explained: Embrace Change (1999).

Like these, extreme programming differs from traditional methodologies primarily in that it places more emphasis on adaptability than predictability. XP proponents view requirements changes on the fly as a natural, inevitable, and even desirable aspect of project development. They believe that being able to adapt to changes in requirements at any point in the life of the project is a better and more realistic approach than trying to define all the requirements at the beginning of the project and then investing effort in controlling the changes in the requirements.

Extreme programming can be considered as the adoption of the best development methodologies according to what is intended to be carried out with the project, and apply it dynamically during the software life cycle.

History

Kent Beck developed extreme programming during his work on the payroll project for Chrysler's Comprehensive Compensation System (C3). Beck became the leader of the C3 project in March 1996. He began refining the methodology of development used in the project and wrote a book on the methodology (Extreme Programming Explained, published in October 1999). Chrysler canceled the C3 project in February 2000, after seven years, when Daimler-Benz acquired the company.

Many extreme programming practices have been around for some time; the methodology follows the "best practices" to extreme levels. For example, the "practice of test development first, planning and writing tests before each microincrement" it was used as early as NASA's Project Mercury, in the early 1960s. To shorten overall development time, some formal test documents (such as for acceptance tests) were developed in parallel with (or shortly before) that the software was ready for testing. An independent test group at NASA could write the test procedures, based on formal requirements and logical limits, before the programmers write the software and integrate it with the hardware. XP takes this concept to the extreme level, writing automated tests (sometimes within software modules) that validate the operation of even small pieces of software coding, rather than just testing the largest features.

Origins

Two major influences shaped software development in the 1990s:

• Internally, object-oriented programming replaced procedural programming as the programming paradigm preferred by some developers.
• Externally, the rise of the Internet and the boom of the pointcom emphasized the speed of marketing and the growth of the company as competitive commercial factors.

Rapidly changing requirements demanded shorter product life cycles and often clashed with traditional software development methods.

The Chrysler Comprehensive Compensation System (C3) was initiated to determine the best way to use object technologies, using Chrysler's payroll systems as the research object, with Smalltalk as the language and GemStone as the layer of data access. Chrysler hired Kent Beck, a noted Smalltalk practitioner, to tune the system's performance, but his role was expanded when he noticed various problems with the development process. He took this opportunity to propose and implement some changes to development practices, based on his work with his longtime collaborator, Ward Cunningham. Beck describes the early conception of methods:

The first time they asked me to lead a team, I asked them to do some of the things they thought were sensible, such as tests and reviews. The second time there was much more at stake. I thought: "To the devil with the torpedoes, at least this will be a good article," [and] asked the team to raise all the edges to 10 in the things that I thought were essential and omit everything else.

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

Information about the principles and practices behind XP was disseminated to the rest of the world through discussions on the original wiki, Cunningham's WikiWikiWeb. Various contributors discussed and expanded the ideas, and some derivative 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 wider audience.

Values

The original values of extreme programming are: simplicity, communication, feedback (feedback) and courage. A fifth value, respect, was added in the second edition of Extreme Programming Explained. The five values are detailed below:

Simplicity

Simplicity is the foundation of extreme programming. Design is simplified to speed development and ease maintenance. A complex design of the code together with successive modifications by different developers make the complexity increase exponentially.

To maintain simplicity, refactoring of the code is necessary, this is the way to keep the code simple as it grows.

Simplicity is also applied in the documentation, in this way the code must be commented in its proper measure, trying that the code is self-documenting. For this, the names of the variables, methods and classes must be chosen appropriately. Long names don't decrease code efficiency or development time thanks to existing autocompletion and refactoring tools.

Applying simplicity along with collective code authoring and pair programming ensures that the bigger the project gets, the more and better the whole team knows the whole system.

Communication

Communication takes place in different ways. For programmers, code communicates better the simpler it is. If the code is complex, you have to make an effort to make it readable. Self-documenting code is more reliable than comments since comments soon become out of date with the code as it is modified. Only what will not change should be commented, for example the objective of a class or the functionality of a method.

Unit tests are another form of communication as they describe the design of classes and methods by showing concrete examples of how to use their functionality. Programmers communicate constantly thanks to pair programming. Communication with the client is fluid since the client is part of the development team. The customer decides which features have priority and must always be available to answer questions.

Feedback

As the client is integrated into the project, his opinion on the status of the project is known in real time.

By running very short cycles after which results are shown, it minimizes having to redo parts that don't meet the requirements and helps developers focus on what's most important.

Consider the problems that result from having very long cycles. Months of work can be thrown overboard due to changes in customer criteria or misunderstandings on the part of the development team. The code is also a source of feedback thanks to the development tools. For example, unit tests report on the health of the code. Running unit tests frequently allows you to discover bugs due to recent code changes.

Courage or bravery

Many of the practices involve courage. One of them is always to design and program for today and not for tomorrow. This is an effort to avoid getting bogged down in design and requiring too much time and work to implement the rest of the project. Bravery allows developers to feel comfortable rebuilding their code when necessary. This means reviewing the existing system and modifying it if it will make future changes easier to implement. Another example of bravery is knowing when to scrap code: bravery to remove obsolete source code, no matter how much effort and time went into creating that code. Furthermore, bravery means persistence: a programmer can sit still on a complex problem for a whole day, and then quickly solve it the next day, only if they are persistent.

Respect

Respect manifests itself in many ways. Team members respect each other, because developers can't make changes that cause existing tests to fail or slow down the work of their peers. The members respect their work because they are always striving for high quality in the product and looking for the optimal or most efficient design for the solution through code refactoring. The members of the team respect the work of the rest, not doing less to others, a better self-esteem in the team increases its rate of production.

Key features

The fundamental characteristics of the method are:

• Iterative and incremental development: small improvements, one after the other.

• Continuous unit testsoften repeated and automated, including regression tests. It is advisable to write the test code before the encoding. See, for example, the JUnit test tools for Java, DUnit for Delphi, NUnit for the platform.NET or PHPUnit for PHP. These last three inspired by JUnit, which, in turn, was inspired by SUnit, the first test-oriented framework, made for Smalltalk programming language.

• Partner programming: It is recommended that development tasks be carried out by two people in the same position. The highest quality of the code written in this way - the code is revised and discussed while written - is more important than the possible loss of immediate productivity.

• Frequent integration of the programming team with the client or user. It is recommended that a customer representative work alongside the development team.

• Correction of all errors before adding new functionality. Make frequent deliveries.

• Refactoring code, that is, rewrite certain parts of the code to increase its legibility and maintainability but without modifying its behavior. Evidence must ensure that no fault has been introduced in refactoring.

• Ownership of shared code: instead of splitting responsibility in the development of each module into different working groups, this method promotes that all staff can correct and extend any part of the project. Frequent regression tests ensure that possible errors will be detected.

• Simplicity in the code: it is the best way for things to work. When everything works you can add functionality if necessary. Extreme programming bets that it is easier to do something simple and have some extra work to change it if required, than to do something complicated and perhaps never use it.

Simplicity and communication are extraordinarily complementary. With more communication it becomes easier to identify what should and should not be done. The simpler the system, the less you have to communicate about it, which leads to more complete communication, especially if the team of programmers can be reduced.

Roles

Programmer

Produces the system code. It is the essence of the team.

Test developer

Produces the system unit test code. It is one of the most important roles.

Customer

Write user stories and functional tests to validate your implementation. Prioritize user stories and decide which ones are implemented in each iteration with a focus on delivering the most business value.

Tester

Interpret the customer request and help the development team write functional tests. Runs tests regularly, disseminates results to the team, and is responsible for test support tools.

Tracker

He is in charge of monitoring. Provide feedback to the team. You must verify the degree of success between the estimates made and the actual time spent, communicating the results to improve future estimates.

Coach

Responsible for the overall process. Guide team members to follow the process correctly.

Consultant

It is an external member of the team with specific knowledge in some subject necessary for the project. Help the team solve a specific problem. In addition, he has to investigate according to the requirements.

Manager (Big boss)

He is the store owner and the link between customers and programmers. His essential work is coordination.