Extreme Programming (XP)

What is Extreme Programming?

Just before the year 2000, Ken Beck, had developed Extreme Programming (XP) during his line of work at Chrysler Comprehensive Compensation System payroll project. Beck had become the project leader of this project, and thus he had refined the development methodology used, which ultimately led him to write a book about the methodology, he named the book “Extreme Programming Explained”.

Extreme programming (XP) is a software engineering process that utilises the Agile Software Development Methodology. XP is intended to improve the software quality and mainly the responsiveness to changing client requirements.

As mentioned above, it’s a form of Agile software development, this means that it follows the notion of having frequent “releases” in short development cycles.

The ultimate goal for this is to increase productivity and to introduce checkpoints at which customer requirements can be amended/added/removed to their liking.

XP will turn the normal traditional software development process sideways, meaning rather than doing the project steps in a linear fashion, programmers do all such activities little by little throughout the development phase.

You can think of it as a jigsaw puzzle, were each small piece alone makes no sense and is confusing, but when everything is combined into one, the bigger picture is shown and each little piece will make sense.

The ultimate advantage of using XP and this approach above is the resilience that it allows, thus allowing easy incorporation of changes to be done and executed.

It may seem from the text below that XP is against documentation, but that’s not true. Yes it is correct that XP produces less documentation overall, which has it’s disadvantages (for instance difficulty to trace where a particular error is for instance), though XP allows for the advancement at least possible work required.

Essential XP artefacts are:

User story cards:

• Contains a short description of behaviour of the system from the customer point of view.
• Must be written by the customer rather than the developers.
• Should provide enough detail to allow an estimation to be provided of how long the story will take to implement.

Acceptance tests:

• One or more tests to verify that the story (above) has been properly implemented.

Estimates:

• Release planning:
  • Effort and duration estimates for the stories that will be used in release planning.
• Iteration planning:
  • Effort and duration estimates for tasks based on the user stores are evaluated. These will be sued in iteration planning for the tasks assignments and load balancing in the commitment phase.

Task cards:

• Contains the required task to implement a user story.
• One task card per user story.
• Forms a basis for task estimates and tasks assignments.

Design:

• Contains a simple design just enough for the implementation of a user story.

Unit test cases:

• Contains unit test cases that drive the coding and unit testing.

Customer and developer communication records:

• Client and the developers will discuss the story that’s created to elaborate on the details. This is verbal when possible, but documented when required.

Values and principles of Extreme Programming

Extreme Programming (XP) has 5 values which are considered to be its rules:

Communication:

• Team members work together at every stage of the project.

Simplicity:

• The development team strive to produce code that is simple and jointly brings more value to the product, as it saves time, effort, and cost.

Feedback:

• The development team produces software frequently, thus allowing them to obtain feedback about the production and improve the product according to the new requirements/feedback that was given.

Respect:

• Every member that is assigned to a project contributes to a common goal.

Courage:

• Developers objectively will evaluate their own performances based on their results without making excuses, furthermore, they are always ready to respond to changes in the right direction.  

The 5 principles that XP follow are:

Rapid feedback:

Rapid feedback is when you obtain feedback, whether that was from a peer or the client themselves, and that feedback is implemented into the system at the fastest rate possible.

The developers design, implement and test the system, furthermore the feedback they obtain is implemented straightaway, rather than days, weeks, or months.

Assumed simplicity:

In order to assume simplicity, developers must treat every problem as if it can be treated in a simple fashion.

To “assume simplicity” means to do a productive job of “today”, furthermore, it also means to trust your ability to add complexity in the future where you need it.

With XP, individuals are told to do a good job (including: tests, refactoring, and communication) focusing on the present, rather than future.

When developers develop good unit test for the software, they can easily refactor the code to do additional test if needed.

Developers follow “YAGNI” (You Ain’t Gonna Need It) and DRY (Don’t Repeat Yourself) principles. For instance: (And Yes! these are real proper principles spelt like that!)

• Do not have multiple copies of the identical code (code duplication).
• Do not have redundant copies of information.
• Do not waste time and resources on what may not be necessary.

Incremental changes:

To implement big complex changes all at once wouldn’t be productive and quite frankly, just won’t work most of the time.

Problems are solved in a series of smaller problems that will build up to the big problem, eventually, once the small problems are executed, the big problem would be executed too in a collective manner.

In XP incremental changes are applied by allowing the design, plan, and team to make changes little at a time.

Embracing change:

If the client requests to make a change in the system, the developers should support the clients decision, moreover, the development team should also propose ideas on how to tackle the new requirement and how it shall be implemented.

Quality work:

A team that works well, that makes a quality rich product according to the requirements of the client and feels proud of it.

Practices involved in Extreme Programming

The following practices at some point in time, were considered to be the best practices in software development.

The twelve practices listed below, detail the specific procedures that are implemented during an XP project.

Fine-Scale feedback

Test-Driven Development:

Tests are created for each and every requirement of the project, once that is completed, only then the code is developed that will successfully pass those tests.

The Planning Game:

This practice involves a meeting that takes place frequently at a well-defined interval every one to two weeks ideally, furthermore, the majority of the project planning takes place in these meetings.

Within this practice, the “Release Planning Stage” exists.

This stage entails determinations with regards to impending releases: Sections of the Release Planning stage are:

Exploration phase:

Story cards are used to detail the most important requirements for customers.

Commitment phase:

Planning and commitments from the team are made to meet the needs of the next schedule release and get it out on time.

Steering phase:

The steering phase allows previously developed plans to be adjusted based on the changing requirements of the project.

The Release Planning Stage is followed by the “Iteration Planning Stage”. Although it has the same sub-phases, there are variations to the implementations.

Exploration phase:

Project requirements are written down.

Commitment phase:

Tasks that are not completed yet to meet the up-coming iteration release are assigned to developers and are scheduled respectively.

Steering phase:

Development takes place and is completed for this iteration, and the result is then compared to the outlined story cards that are created at the start of the planning procedure.

On-site Customer:

The customer should be available at all times to answer any questions the development team may have, furthermore, the customer should also set priorities and resolve any disputes if necessary.

Pair Programming:

Pair programming means that two people on the development team, work together on the same system when developing any production code.

Rotating partners frequently within the development team, allows for better communication and team building.

Continuous process

Code Refactoring:

The essence of code refactoring is to improve and redesign the structure of the code that already exists, without adjusting or modifying the behaviour of the code.

Code refactoring can be the simplest of issues, such as, fixing improper named variables, methods, and removing code duplication.

Continuous Integration:

The idea behind continuous integration is that all the code from different teams is merged together into one repository many times a day (just like using GIT for instance).

Continuous integration will ensure that all the code is updated in the same place and that if any problem is noticed, all the teams will notice it and thus a quick fix is more plausible rather than dragging it along.

Small Releases:

Very similar to the practices of the “Iterative Model”, this practice ensures that the project will function in a way that allows small releases to be produced on a frequent basis, thus allowing the client to get a sense of how the project is progressing, and allowing them to provide feedback during each release if needed.

Shared understanding

Simple Design:

Basic principle of keeping everything simple, whether that was functionality or design, this ensures that the team are constantly evaluating whether things can be done in an easier way.

Coding Standards:

As with any project theoretically, developers should maintain the best practices within code itself, for instance styling and formatting, everyone on the entire team should abide by these coding standards throughout the life cycle of the project.

The advantage of this, is that it advocates better understandability of the project as-well as readability of the code, not only for current members of the team, but for future developers who are required to understand the code they’re dealing with.

Collective Code Ownership:

Collective code ownership refers to the whole team’s responsibility for the design of a system, allowing each team member to review and update the code produced.

This practice helps to avoid code duplication as each developer will know where to add new features if needed, moreover, this feature will allow collective code ownership which encourages the team to implement more and feel more open to bring new ideas onto the table to be considered in the next iteration.

System Metaphor:

System metaphor refers to the idea that every team member should be able to look at the high-level code that is developed for the project, they should also have a clear understanding of the functionality that code is executes and thus how the system performs it.

Programmer welfare

Programmer Work Conditions:

XP require the developers to be efficient and fast to sustain high quality production.

To comply with these requirements, developers should feel well and rested to allow them to be at their most optimum potential when developing, thus developers are required not to exceed 45 hours of work per week. This will prevent them from what is referred to as “burnout”.

When to use Extreme Programming?

XP can work well for teams that:

• Except their system functionality to get altered every iteration/few weeks.
• Experience constant change in requirements or even work with a client that has changing requirements frequently. (i.e. working with someone who doesn’t know what they fully want yet)
• Want to mitigate project risk, especially within tight deadlines.
• XP advocates for a small number of programmers within the team, ranging from 2-12 personnel.
• Developers have good communications skills and are patient as they will have to work quite closely to the client.
• Necessary to create automated unit and functional tests.

Advantages of Extreme Programming

Fast:

Rather than develop software and a functioning system that takes potentially years, XP projects relatively only last for several months. This is due to the fast paced work environment that XP implements, thus reducing the amount of time wasted and working on what’s important during each iteration. All of this allows continuous integration and deployment.

Visible:

XP allows open communication between team members and development teams, this allows everyone to keep up with the project advancement and progress.

Meetings are held regularly to make sure that everyone knows their tasks and to record the progress made.

All of this will limit the number of bugs and failures in the system.

Reduce costs:

Due to the fact that XP implements constant teamwork and feedback from the client, this allows changes to be made when necessary and at the earliest time possible. These alterations in the requirements or any new modifications required are implemented in the development period rather than at the end. Unlike the Waterfall methodology, they have to wait to the very end for feedback, and depending on the change, it could be detrimental for the project, hence why requirements must be very precise with Waterfall.

Teamwork:

XP has an extremely strong influence on teamwork, which allows developers to accomplish the requirements they were set out to do within tight deadlines.

Strong relationship with the client:

XP strongly recommends that the project owner/client is available when needed so that any questions can be asked or any revisions are to be made to obtain necessary feedback so it can be implemented in a more efficient manner.

Disadvantages of Extreme Programming

Code overcomes design:

XP focuses too much on the programming aspect of the system and its importance outweighs the design.

This can be disadvantageous if the particular system requires aesthetics to be one of it’s selling point or important characteristics.

Location:

XP project work at their best when the client and development team are close to each other (distance wise) so they can meet face to face.

This limits the environments in which XP can be implemented due to many clients and development teams tending to work using long distance mechanisms.

Lack of documentation:

There is no hiding that XP allows for constant alterations with the project, however, these constant changes are rarely document properly. This therefore allows a high risk of unexpected failures that cannot be tracked, which then induces a domino effect that will inevitably end up reducing team efficiency and productivity.

Even when the bugs are fixed, if there is no proper documentation, the same error or something similar can surface again.

Stress:

Due to the nature of XP and how it functions with tight deadlines, developers tend to have high stress levels to complete tasks on time, thus increasing the chances of errors in the code. Subsequently, software quality could be reduced due to the scheduling.

Summary and Facts

What is Extreme Programming?

• Extreme Programming (XP) is one of the numerous types of Agile frameworks that is applied by IT companies globally. One of it’s key features of XP is the emphasis on technical portions of the software development, thus distinguishing it from other approaches.
• XP is intended to improve the software quality and mainly the responsiveness to changing client requirements.

Values and principles of Extreme Programming:

Extreme Programming (XP) has 5 values which are considered to be its rules:

• Communication
• Simplicity
• Feedback
• Respect
• Courage

The 5 principles that XP follow are:

• Rapid feedback
• Assumed simplicity
• Incremental changes
• Embracing change
• Quality work

Practices involved in Extreme Programming:

Fine-Scale feedback

• Test-Driven Development
• The Planning Game
• On-site Customer
• Pair Programming

Continuous process

• Code Refactoring
• Continuous Integration
• Small Releases

Shared understanding

• Simple Design
• Coding Standards
• Collective Code Ownership
• System Metaphor

Programmer welfare

• Programmer Work Conditions

Advantages & Disadvantages of Extreme Programming

Advantages	Disadvantages
Close contact with the customer	Provides additional work
Development allows for no unnecessary work to be done	Client must be available regularly (face to face is recommended)
Error avoidance through the use of pair programming	Code is more superior than design
No overtime, avoids employee burnout	Requires vision management
Changes can be made at short notice	Requires team members to be self disciplined
Code is clear and comprehensive	No proper documentation is produced constantly with ever requirement amendment/addition/removal

References:

1. https://www.altexsoft.com/blog/business/extreme-programming-values-principles-and-practices/
2. https://www.brighthubpm.com/methods-strategies/88996-the-extreme-programming-life-cycle/
3. https://www.agilealliance.org/glossary/xp/#q=~(infinite~false~filters~(postType~(~’post~’aa_book~’aa_event_session~’aa_experience_report~’aa_glossary~’aa_research_paper~’aa_video)~tags~(~’xp))~searchTerm~’~sort~false~sortDirection~’asc~page~1)
4. https://airbrake.io/blog/sdlc/extreme-programming
5. https://en.wikipedia.org/wiki/Extreme_programming#Origins
6. https://simpleprogrammer.com/pros-cons-extreme-programming-xp/
7. ionos.co.uk/digitalguide/websites/web-development/extreme-programming/
8. https://medium.com/@azimidev/extreme-programming-xp-35223784976e
9. https://www.tutorialspoint.com/extreme_programming/extreme_programming_activities_artifacts.htm