Extreme programming

A wave of programming mantras is changing the way developers look at projects. Stewart Mitchell lifts the lid on a different kind of XP.

Don't be confused; this XP has little to do with Microsoft. It's what happened when software developers pushed the best practices of programming to the edge, to the extreme.

Extreme programming is a major departure from tradition. Gone are the solitary pizza-eating coders. Extreme programmers work in pairs as part of a team, labouring towards a common goal of better, cheaper software. Instead of individual coders working on a project in cubicles and assembling their output to see what works in a beta release, XP promotes constant iteration, assessment and communication. Established in 1996 with the launch of Kent Beck's Extreme Programming Explained: Embrace Change, the methodologies were quickly taken on board and the first implementation was seen at Chrysler in the late 1990s.

Regardless of the programming language, XP concentrates on customer satisfaction and lightweight code, in theory allowing software focus to change with market requirements. The XP movement has already converted HP Middleware, IBM, IONA Technologies and Ford, and the gospel is spreading.

All is not rosy. For many people, even the name suggests risk and volatility and, while some big companies have used its methods, it hasn't gained widespread uptake. Certain groups use some of XP's ideas and reject others and the movement is being taken under the umbrella of 'agile programming', in which several new-age methodologies are lumped together. We'll focus on XP, but other agile methods have similar values: to promote speed and flexibility in development.

So should you use an XP team when you want your next mission-critical business application built? Will software become cheaper on the high street, and would you enjoy working in such an environment? Let's see.

XP on test
There are 12 tenets of XP (see box page 97) that form the basis of this almost religious movement and, while some seem obvious, a few rip up the 'traditional' programming rulebook. Development houses may not use all 12 practices, but some are central to the XP method. First is the concept that unit tests to validate code must be written before the code itself – a major reversal of traditional concepts. Application requirement tests must be passed by all code before it's taken further, and no code is written without the sole intention of passing the tests. Advocates argue this creates slimline code that leaves the core software open to inspection and adaptation later – an important consideration, given the 'just in time' nature of XP leaves little room for future planning.

Sceptical management, however, questions the value of programmers concentrating on tests when they could be coding.

'They say: “I don't want my programmers writing tests, I want them writing code”,' said David Putman, development leader at UK-based developer Workshare, which boasts the biggest XP programming staff in the world. 'But how do you know their code works? And even if you write the code then create the tests afterwards, how do you know all the tests will cover all the code? If you do the tests first, then only write code to pass them, you know that once the test is passed you've finished coding.'

The argument for constant testing flows through to integrating code into the application, and can help prevent instability.

'If you connect all those tests and put them on your integration machine, every time anyone integrates code it's tested. If anything then breaks, you know there's a knock-on effect,' Putman said. 'One of the problems of traditional programming is that an innocuous change can have a knock-on effect that brings down the whole application.'

One step at a time
One of the difficulties XP and other agile programming schools try to overcome is the inflexibility of traditional programming. Business requirements change with the weather, so what happens to software designed six months ago that is obsolete before it's even presented to customers? A spokesperson from a large government agency told PC Authority one of the main expenditures when creating the department's self-assessment software was brought about by changes in legislation: 'Every time we thought we had the system working, there was a legislative decision that meant we had to pass changes onto the contractors and programmers, who had to go back to the drawing board,' said the official. 'Often that meant losing months of work, which cost both money and time.'

XP addresses these problems by making iteration releases so regular and minor that any change of plan doesn't involve the loss of weeks' or months' work. It's also XP practice to have someone from the customer side help with testing and advise policy change.

'It's about people and communication,' says Putman. 'You say to the customer: “This is what you said yesterday and this is what I've done. Do these things match and meet requirements?” In the old days of the waterfall process, you'd have someone spend three months writing a design document, only to learn the customer changed their mind and wanted changes done free.'

Many XP teams expect to make releases and get daily feedback – there's no waiting for version 1. This means the change to costs across the life of a project remain constant, particularly compared with the debugging associated with more orthodox programming.
The constant testing and iterations mean an XP project evolves, and this is central to the ideology.

But the idea that programmers can change direction quickly because of small iterations would fall apart were it not for what the evangelists call 'refactoring'. This addresses what otherwise might prove a shortcoming in XP – its refusal to code for the future. By insisting the final code is solid, pared down so that only the mandatory essence remains, XP leaves code in a state where future work can be integrated with minimal rebuilding.

Two by two
There are other arguments against XP, mainly management issues in which non-programmers question core practices. They often focus on the most radical ideas of the XP bible – such as pair programming. Programmers work in pairs, at one machine, with one person 'driving' and the other guiding, advising and checking for mistakes.

'Some people say that two people sitting at a machine, working on the same code, costs twice as much,' said Putman. 'But most programmers spend a lot of time wondering how to solve a problem, and not actually coding. Two people together are more likely to work it out quickly.' The joint ownership of code also means programmers can ask others in the team for assistance and expect them to help and to understand the problems.

'Having a second pair of eyes going over all code means there's less chance of errors, which saves masses of time,' said Putman. 'We reckon that pair programmers are three times as fast as individuals.'

Researchers at the University of Utah put the figures much lower, saying pairs produce less work than two individuals, but agree that code is 15 per cent cleaner. Programmers we spoke to had mixed feelings about working in tandem. Some preferred the lone existence of traditional coding, some felt pair programming would be intimidating, and others liked the social interaction of an XP project.

Conclusion
For developers and programmers there are compelling arguments for the switc