Extreme Programming is an application of the Agile software development framework. Its goal is to make better software and improve the quality of life for the team members.
How does extreme programming work?
Extreme programming (XP) is an adaptive programming style designed to listen to feedback from both the customer and engineers to deliver a good, and possible, product on time. It is adaptive in the agile methodology in that it is responsive to:
- Customer demand
- The possibilities available to your company and your industry
XP is not meant to be used in all software development projects. A particular distinction is that XP is a development framework for fixed-time projects. This is very different from something like Continuous Integration and Development (CI/CD).
Some industries have a pulse to them. Apple puts out a new phone every year, a publisher may push a book every couple months, a software team may release a new version of their software once a year. Extreme Programming has proven beneficial in these environments where you have to meet regular deadlines.
XP team size
Extreme programming consists of small teams of 2 to 12 people. It is possible for an XP team’s size to grow, but the root purpose—adaptability—must still be possible.
Sometimes, more team members come at the cost of adaptability.
XP team roles
It is common to see XP teams include many different roles, not only developers. Like other agile frameworks, an XP team will consist of:
In XP, you can also have two new roles: The Tracker and the Coach.
- The Tracker. A role a developer generally fills to track particular key metrics of the team’s performance, such as software quality. The role is not necessary. You’ll create it on a need-only basis.
- The Coach. An outside party who can watch and monitor the team’s performance; this person is often a consultant or a mentor.
(Learn more about Agile team roles.)
XP practices
Extreme Programming is all about communication, simplicity, feedback, courage, and respect. Common XP Practices are:
- Pair Programming
- ChatOps
- Continuous Integration
- Continuous Testing
- Frequent breaks! Focus is important for good programming; overworking can hurt your ability to focus.
Get started with extreme programming
First, you need to determine if this methodology is right for you. XP won’t work:
- If the project is concurrent middleware development. Too many usage scenarios doesn’t work with XP, and reliable unit testing is impossible.
- If the project is OS Kernel and device drivers.
- If change is too costly or if you must closely monitor change to preserve safety.
For more specifics, refer to this article.
Second, start a new project. Projects begin with the user. What are their stories? What are their use cases? What is the solution?
- Develop the communication lines early. If it’s done late in the project, what’s the purpose of doing this methodology in the first place? Rule number one is to communicate so the team can adapt. Start clear communication early. Make it a standard for any project at the outset.
- Pay attention to the progress of code development. You can paint broad strokes first to get a picture of the finished idea without coding, and then fill in the details later. (Abide by the law of diminishing returns.)
- Test your application regularly with the user. You do not want to stray too far from the use case. If you do, see if it can be changed to align more with the user’s vision, and don’t be afraid to scrap and start anew. The purpose of agile development is to avoid spending a lot of resources to, in the end, find you need to fit a square peg into a round hole. In agile development, it should be known well-ahead of time the whole is round, and to develop the peg accordingly.
Once these items are in place, XP programming should not feel like a system to strive to achieve, but a natural working order that keeps everyone on track, focused, and relaxed.
The regularity of the product release cycle inherent with Extreme Programming can increase everyone’s sense of time, allowing the excitement to begin when a new project starts, and the happiness, and relief, to follow when a project comes to its deadline.
Related reading
- BMC DevOps Blog
- Scrum vs Kanban: A Comparison of Agile Methodologies
- The Scaled Agile Framework (SAFe): What To Know and How To Start
- DevOps Metrics & KPIs
- Asynchronous Programming: A Beginner’s Guide
- Python vs Java: What’s The Difference?
These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.
See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.
