Some weeks ago we've talked about Lean Development, set of software development principles and practices based on lean thinking and waste reduction. In this article we will dedicate ourselves to the deepening of another software development methodology belonging to the vast set of Agile methodologies: Extreme Programming, also known as XP.
Indroduction
Extreme Programming ( XP) is an Agile software development methodology that emphasizes writing quality code while also responding to changing requirements. It is one of the first agile methodologies to have established itself in the software community, meeting particular success in the late 90s and early 2000s.
Developed almost entirely by Kent Beck by putting together different techniques already in use, Extreme Programming is, according to many, the methodology that more than any other has favored the affirmation, diffusion and application of Agile concepts - originally designed for the manufacturing industry, i.e. based on production facilities - within software development.
Distinctive elements
Extreme Programming belongs to the family of Agile methodologies, and as such prescribes iterative and incremental development structured in short development cycles.
Its distinctive elements are:
- Pair programming: two programmers work together on one workstation, the driver is the one who writes the code while the navigator thinks about the approach and thinks if it can work.
- Planning Game: planning meeting that happens once per iteration (or sprint).
- Test Driven Development: Write self tests before writing code.
- Whole Team: the client (or the end user) must participate in the check, testing and feedback phases.
- Continuous integration: integrate the changes made to the code as quickly as possible (with specific version control software and very frequent updates).
- Refactoring: rewriting the code without altering its external functionality, changing the architecture, in order to make it simpler and more generic.
- Small Releases: Provide frequent feature releases that create real value.
- Coding Standards: adoption of a code writing standard, which is a set of agreed rules that the entire development team agrees to abide by.
- Collective Code Ownership: Each developer is responsible for all code.
- Simple Design: Use a KISS (Keep it Super-Simple) approach to design.
- System Metaphor: use metaphors to describe the system (user stories, epics, etc.).
- Sustainable Pace: Each developer should work no more than 40 hours per week.
Other noteworthy principles include: the prohibition of programmers from developing unnecessary code, the emphasis on clarity and simplicity of the code, the preference for non-hierarchical management structures, and the importance given to direct and frequent communication between developers and customer.
Why "extreme"?
The term Extreme can easily mislead and push developers to get an incorrect idea about this methodology: however, there is nothing really extreme in the its application. The meaning of the word relates to the fact that the twelve principles on which the methodology is based are nothing more than an extension of several good practices already in place among most developers (and adopted by almost all desktop & mobile software development companies), which are however taken to the extreme.
A perfect example to understand the concept is given by the Test Driven Development rule, which provides for the systematic use of Unit Tests: the "extreme" application of Unit Tests means that the latter cease to be simply useful tools to be used from time to time. just to become an integral part of code development. Specifically, a software developer adopting the Extreme Programming methodology will apply the Test Driven Development rule by converting all software requirements into specific test cases: since the code has not yet been implemented, the initial condition of each of these tests will be fail ( or red, from the color conventionally assigned to the test that fails), and then becomes pass (green) after implementation.
The developer's job then becomes the following:
- Transform development items into test cases, each of which will have initial condition fail (red).
- Write the new code (or modify the existing code) by implementing the required functionality, so as to bring the test into a pass condition (green).
- Improve the developed code (refactoring), without modifying its functionality and taking care to keep the test in pass condition (green).
The succession of these three phases gives life to a real iterative process, as represented by the following image:
A "sustainable" pace
Another distinctive feature of Extreme Programming is that of being the only Agile methodology that emphasizes not only the empowerment of developers (Whole Team and Collective Code Ownership), but also the sustainability of work (Sustainable Pace): a particularly important in a period like the current one, in which development teams are often forced (by the business, by the market, by users, etc.) to sustain intense and prolonged development periods (the so-called crunches).
Inserting the Sustainable Pace within the working methodology is intended to strongly discourage the idea of resorting to a crunch, which thus becomes a violation of the working method analogous, in principle, to other exceptions generally considered more dangerous (e.g. relaxing security).
Conclusions
That's it for now: we hope this article will be useful to all developers and project managers interested in learning more about and / or adopting this development methodology. Until next time!
