Twelve commandments of XP
In a flashback to the cartoon industry, the XP ethos encourages customers to 'storyboard' their projects, drawing a picture of exactly what they want the software to do and which areas are most urgent – either strategically or financially.
2 Little by little
Iterations come thick and fast with XP. Starting as early as possible with a simple system, almost every development is released into the application as soon as it's ready.
3 Name game
To aid communication and administration, programmers across teams use a common system of names for their work.
4 Carpe diem
The XP program only does what's required for its current goals, as simply as possible. Little is planned for future development, with the emphasis on scaling at a later date.
5 Try and try again
Validating software constantly is a major rule in XP, where tests are written before the software. Once tests that reflect the customer's requirements are written, programmers work on developing software that passes those tests. Customers should provide further tests to ensure that the software actually does what the users require.
6 Keep fit
XP programs are intended to grow like a gym freak – trim and well-proportioned. Duplication is kept to a minimum by continually working on the overall code design – a process termed 'refactoring' by the XP world.
7 What a pair
XP programmers work in pairs on one terminal. While one 'drives' by writing/inputting, the other watches for mistakes in syntax or for typos. The pair change positions regularly. Some programmers think this approach is more productive, while others find it uncomfortable.
8 Community services
The XP has a collective mentality that all code belongs to everyone. This is supposed to mean that changes can be made without any delay.
9 Integrated circles
The software is integrated and built several times a day, so that all programmers understand where the project is moving. Advocates claim that frequent integration means fewer integration problems.
10 Tiredness kills
The pure XP concepts call for a maximum working week of 40 hours — anything else leads to mistakes that are both costly and time-consuming.
11 Customer contact
The XP project calls for an on-site customer representative so the end-user requirements remain the prime concern and any changes in priority can quickly be brought to the fore.
All programmers must write code similarly to allow cross-team communication.
What's in a name?
The term 'extreme programming' has come under fire because, while Beck and others thought the name gave the practice a chic allure at a time when extreme sports were all the rage, many management teams thought it sounded too radical for CFOs and other decision makers. 'Extreme' as a term conjures images of risk, whereas its replacement, 'agile', appeals to those seeking flexibility and speed.
So although only a few years old, as a term it's under threat, with 'agile programming' and 'lightweight software development' taking its place. Rival methodologies – SCRUM, DSDM, Adaptive Software Development, Crystal, Feature-Driven Development and Pragmatic Programming – are similar in practice to XP in that they adapt to, instead of anticipating, programming requirements.
Each of the agile methodologies within the Agile Programming Alliance come from different gurus, with advocates having a vested interest as they wrote the relevant books and rely on consultancy from their methodology.
There's also an argument blaming Microsoft for the name change, saying XP meant only extreme programming before the launch of the latest Windows OS, but this is anecdotal. What is certain is many of the attributes of XP have found themselves used in other areas of agile programming, and whether the name XP survives isn't as important as the changes in the processes borne out of the methodology.
The case against. . .
There's no one-size-fits-all formula for developing software and, while XP works for many languages and projects, even fanatics agree there are barriers to XP.
1 Extreme and agile programming go hand in hand with object-oriented technology and are best suited to those more modern languages. However, one of the barriers to XP is C++, because although it's object orientated, it's quirky.
2 Large teams make XP more difficult, because it's communication based. Each project member relies on the communication skills and knowledge of his team and there can be serious diseconomies of scale.
3 Distributed applications using COM, where functionality is stored in different executables, proves difficult because you end up with too many DLLs. With COM architecture, it's problematic to run unit tests across boundaries, and that makes life hard in the testing arena of XP.
4 GUI-intensive applications don't lend themselves to XP — again, because it's more difficult to carry out XP testing practices with something that's on the screen. This has to be done manually, so XP developers tend to separate the functionality from the GUI for testing.
5 Legacy code isn't written for testing, so moving to XP means going back into legacy code to write it.