Many developers running traditionally organised software projects struggle to deliver business value, particularly within what has been described as internet timescales. In response to this, agile methods, which accept changing requirements as a natural part of successful development projects, have grown in popularity.
Agile software development comprises a number of methodologies that, while differing in detail, share a common emphasis on:
- collaboration between programmers and business experts;
- face-to-face communication;
- frequent incremental delivery of working software;
- the ability to respond to changing requirements throughout the development process;
- self-organising teams.
These principles formed the basis of the 2001 Manifesto for Agile Software Development, which states:
'We have come to value...
- individuals and interactions over processes and tools;
- working software over comprehensive documentation;
- customer collaboration over contract negotiation;
- responding to change over following a plan.
'That is, while agile developers value items on the right, more emphasis is placed on the items on the left.'
What is XP?
Extreme programming (XP) is one of the best-known forms of agile development with a particular emphasis on the engineering practices within the programming team. It was first developed by Kent Beck in the late 1990s. In the agile development spectrum, XP sits at one end with variants that emphasise project management, such as Scrum, at the other end.
Some of the engineering practices most associated with XP are pair programming, test-driven development, refactoring and continuous integration. These are all aimed at improving code quality and responsiveness to change.
Pair programming improves quality through the collaboration of two developers based on the principle of two heads are better than one. Alternatively, it can be thought of as continuous code review. Pair programming is a very effective method of spreading knowledge throughout the development team, particular when new members join. Pairs also tend to hold each other accountable for maintaining the team's practices and standards.
Test driven development (TDD) ensures full test coverage, as all the tests are written before the code tested. However, the scope of TDD is much wider than the traditional role of programmer's unit tests. In XP, the entire test suite constitutes an executable definition of the software being developed. As such, this definition is always in line with the behaviour of that software, unlike paper-based specifications that often diverge from the system as finally delivered.
TDD is also a process of continuous design. Functionality is added incrementally by specifying the newly required behaviour in the form of tests. This focuses development on the essence of each business requirement and prevents programmers from adding unnecessary 'bells and whistles' into the code.
The process of writing tests enforces good design. It is hard to write tests for a system that is not loosely coupled and highly cohesive. If adding new tests becomes difficult, it is a signal to the programmer that the system's design is deficient.
Refactoring is the process by which the design of existing code is improved without changing its behaviour and is intimately linked to test-driven development. The existence of unit tests allows the structure of code to be improved with the confidence that any side-effects will be detected.
An XP project should have no integration phase. Instead, it should employ continuous integration. This involves the frequent checking of all code changes into a central repository and regular automated builds of the entire system. This ensures that a working system, incorporating the latest changes in functionality, is always available.
The customer's role is crucial to XP. The customer should be part of the development team. If this is not possible, the customer should be available for regular face-to-face discussions with the programmers. The customer specifies business functionality in the form of user stories and also supplies acceptance tests that verify that the stories have been implemented correctly. Ideally these tests should be automated so that they can be run alongside the programmer's unit tests during the automated build process.
Since the initial description of XP, the role of the customer has changed and could now refer to a team of individuals, rather than a single person. However, XP continues to maintain a rigorous separation of programmer's technical responsibilities from the business responsibilities of the customer.
In common with other agile methods, XP aims to deliver software in short increments. These increments are generally one or two week periods and are referred to as 'iterations'. XP's planning process emphasises maximising business value. The customer is able to change the features and priorities in each iteration, based on implementation estimates provided by the programmers. This interaction between customers and programmers to formulate the release plan is known as the planning game and is what drives an XP project forward.
Embracing change
The subtitle of Kent Beck's book that first described extreme programming was 'embrace change'. This remains XP's promise.
XP rejects the common assumption that a software project must undergo rigorous requirement gathering and design phases before the development of software can begin. Instead it postulates that software can evolve as features are implemented and customers respond to that software with a deepening understanding of what the next key business requirement is.
Continuous collaboration between programming and customer members of the development team means a speedy response to changing requirements is possible and, as a result, software that provides maximum business value can be delivered rapidly.
Controversy around XP
The iterative nature of development and the emphasis on face-to-face collaboration between programmers and customers instead of requirement and design documentation makes extreme programming controversial. To many, it could seem to be an excuse for hacking code in an uncontrolled fashion. Another common criticism is that pairing is an expensive use of programming staff.
In response, XP's advocates point to the failure of many projects based on the traditional document heavy 'waterfall' process and stress that incremental design is not the same as no design. Additionally, XP's emphasis on engineering practices makes it a highly disciplined process. XP's advocates say that pair programming more than justifies its cost for the improvement in code quality and reduction in bugs.
XP in application
The day-to-day programming practices within an extreme programming team and the planning process are radically different from that of a traditionally organised project. As such, it is difficult to adopt XP merely by reading descriptions of it.
Engineering practices such as pair programming and test-driven development contradict many accepted methods of working and can initially be difficult for some programmers to adopt successfully.
The crucial customer role is even more difficult to master as it involves not only a new way of interacting with the programmers on the team, but also managing the impact of iterative development on the rest of the business. This is often harder than changing the way that the team operates.
These difficulties in transforming practices mean that a key requirement for the successful adoption of XP is the coaching and mentoring of both the programming and business members of the development team.
The future
Over recent years, agile methods in general, and extreme programming specifically have grown in popularity. Despite this, the early adopter phase is still underway and how generalised XP becomes will depend of the success of these early projects. As with much of software engineering, empirical evidence is scarce, but there is now a growing body of successful XP projects.
