Extreme Programming is a software development methodology designed to improve the quality of software and its ability to properly adapt to the changing needs of the customer or client. During the mid and late nineties, while working on the Chrysler Comprehensive Compensation System (C3) to help manage the company's payroll, software engineer Ken Beck first developed the Extreme Programming methodology. In October 1999, he published Extreme Programming Explained, detailing the entire method for others, and shortly thereafter the official website was launched as well.
Similar to other Agile Methods of development, Extreme Programming aims to provide iterative and frequent small releases throughout the project, allowing both team members and customers to examine and review the project's progress throughout the entire SDLC.
Throughout this article, we'll examine exactly what Extreme Programming is and how it works, from the values and principles that are behind it, to the rules and procedural best practices that are used to implement a new Extreme Programming project, so let's get started!
Some more specific takes on SDLC include:
|Rapid Application Development||Test-Driven Development||Waterfall Model|
|Iterative Model||Software Development Life Cycle||Scaled Agile Framework|
|Agile Model||Scrum||Rational Unified Process|
|Big Bang Model||V-Model||Conceptual Model|
|Kaizen Model||Kanban Model||Spiral Model|
These five fundamental values provide the foundation on which the entirety of the Extreme Programming paradigm is built, allowing the people involved in the project to feel confident in the direction the project is taking and to understand their personal feedback and insight is as necessary and welcome as anyone else.
Simplicity: We will do what is needed and asked for, but no more. This will maximize the value created for the investment made to date. We will take small simple steps to our goal and mitigate failures as they happen. We will create something we are proud of and maintain it long term for reasonable costs.
Communication: Everyone is part of the team and we communicate face to face daily. We will work together on everything from requirements to code. We will create the best solution to our problem that we can together.
Feedback: We will take every iteration commitment seriously by delivering working software. We demonstrate our software early and often then listen carefully and make any changes needed. We will talk about the project and adapt our process to it, not the other way around.
Respect: Everyone gives and feels the respect they deserve as a valued team member. Everyone contributes value even if it's simply enthusiasm. Developers respect the expertise of the customers and vice versa. Management respects our right to accept responsibility and receive authority over our own work.
Courage: We will tell the truth about progress and estimates. We don't document excuses for failure because we plan to succeed. We don't fear anything because no one ever works alone. We will adapt to changes when ever they happen.
Initially published by Don Wells in 1999, the proprietor of the Extreme Programming website, this set of Extreme Programming Rules were originally intended to help to counter the claims that Extreme Programming fails to support some of the prominent disciplines necessary for modern development.
Created using what were considered the best practices of software development at the time, these twelve Extreme Programming Best Practices detail the specific procedures that should be followed when implementing a project using Extreme Programming.
In essence, pair programming means that two people work in tandem on the same system when developing any production code. By frequently rotating partners throughout the team, Extreme Programming promotes better communication and team-building.
Often this takes the form of a meeting at a frequent and well-defined interval (every one or two weeks), where the majority of planning for the project takes place.
Within this procedure exists the Release Planning stage, where determinations are made regarding what is required for impending releases. Sections of Release Planning include:
Following the Release Planning is also the Iteration Planning section, which consists of the same three sub-phases of its own, but with variants on their implementations:
While an entire article could be written about test-driven development, the concept is fairly well known among developers and effectively means that tests are generated for each and every requirement of the project, and only then is code developed that will successfully pass those tests.
As with many other SDLC methods and practices, Extreme Programming promotes the inclusion of customers and clients throughout the entire process, using their feedback to help shape the project at all times.
Another common practice in modern development, the idea behind continuous integration is that all code developed across the entire team is merged into one common repository many times a day. This ensures that any issues with integration across the entire project are noticed and dealt with as soon as possible.
Another very common practice, the idea behind code refactoring is simply to improve and redesign the structure of already existing code, without modifying its fundamental behavior. Simple examples of refactoring include fixing improperly names variables or methods, and reducing repeated code down to a single method or function.
Very much in line with the practices of the Iterative Model, this concept ensures that the project will feature iterated, small releases on a frequent basis, allowing the customer as well, as all team members, to get a sense of how the project is developing.
The coding standard is simply a set of best practices within the code itself, such as formatting and style, which the entire team abides by throughout the life cycle of the project. This promotes better understanding and readability of the code not only for current members, but for future developers as well.
Collective code ownership
This practice allows for any developer across the team to change any section of the code, as necessary. While this practice may sound dangerous to some, it speeds up development time, and any potential issues can be quelled with proper unit testing.
There's little reason to complicate things whenever a simpler option is available. This basic practice of keeping all components and code as simple as can be ensures that the entire team is always evaluating whether things could be done in an easier way.
Best thought of as part of the coding standards, the system metaphor is the idea that every person on the team should be able to look at the high-level code that is developed, and have a clear understanding of what functionality that code is performing.
A key concept for better work-life balance with developers on an Extreme Programming project is the notion that nobody should be required to work in excess of the normal scheduled work week. Overtime is frowned upon, as is the concept of "crunch time", where developers are expected to work extreme hours near the end of a release to get everything completed on time.