Test first, then code. Don't build for the future. Work in pairs at one keyboard. Keep strictly to contracted hours. Don't do overtime. Welcome to extreme programming, or XP, a discipline which is turning the wisdom of software development on its head.
XP is attracting the attention of banks weary of big, up-front costs by heavyweight methods and consultancies. It was used successfully at Bayerische Landesbank, Credit Swiss Life and UBS. It has also attracted software houses developing e-commerce applications. E-businesses, too, find traditional development methods aren't flexible enough to meet the pressures of constant change.
Any programmer can do it and be productive. New graduates sit with veterans and find they are making a serious contribution. Ego clashes and abstract arguments about design and architecture are a thing of the past. Software is delivered on time with no significant bugs and to the customer's requirements. This is because the client is involved.
John Nolan is chief technology officer of leading XP exponent Connextra. "XP recognises something might happen that changes what you're doing every day," Nolan says. "Don't be afraid of that. Set yourself up so you can react quickly to changes. When you anticipate, time is sucked away on future value rather than current need. One thing we've learned is when you predict too far, you get caught out."
There are no huge requirements, architecture and design documents. Customers and developers work together creating small "story cards", written in the customer's own language. They agree a small set of working software features to be delivered in one to three weeks.
Two developers work on each story card which describes one task. Then, that pair will split up and each coder will team up with another partner to work on a new card. During the project, the developers will be working with a variety of people whose backgrounds and approaches are different to their own.
But is having two people at a terminal, snatching the keyboard from one another as they thrash things out, a recipe for friction? "People ask if we're talking about ego-less programming. I say it's the opposite. We've got extremely strong egos," Nolan says.
"There's no hiding place. If you're pairing, you make things work. You can't hide in code. When you first write tests, you're collaborating on what you're trying to achieve. You've got through most barriers that cause arguments, like not understanding what the other is doing. Remember, you are working on a single task card producing a small piece of code. Most big arguments are about abstract things."
There's no danger that by focusing on small areas, developers will lose track of context, says Nolan. "By concentrating on small things and moving about, you learn more. You're not starting with the big picture and working in. The most important thing is working software. But, sometimes, we do have architectural discussions."
Connextra's head of development, Tim Mackinnon, says once you've worked out the test for the function being developed, the code becomes trivial. Much more important is refactoring, which is unique to XP. This involves a constant reappraisal of code. It removes redundancy, unused functions, clutter and complexity.
"Actively swapping partners is an important part of refactoring because you spot duplications. When I pick a card, and somebody works with me, the first thing we'll talk about is what we did before. We'll check for copies, remove them and test, making sure we haven't removed functionality. Then we get on with the code."
Pairing has advantages when it comes to what MacKinnon calls the "bus factor".
"How many people can be hit by a bus before the project is dead?" he asks.
"In many teams it's one. In ours it's any number minus one - as long as we've got one left, we'll be okay."
As for a nine-to-five day, it's a matter of common sense. "Programmers are told they're heroes as they work a 90-hour week," Mackinnon says. "That's stupid, because you make mistakes."
The XP philosophy argues that long hours make it less likely you'll hit deadlines.
Nolan says apart from a software product delivered with no bugs, the benefits of XP for Connextra includes fulfilled and highly motivated programmers.
"It makes recruiting simple. When we hire, they hit the ground running. They don't spend time reading manuals. Part of our interview process is people working with us for half a day. People release real code during the interview. One person said his first day at work was his second working for us."
Banks and software houses interested in XP have sent programmers over for half a day. They, too, contribute.
"There is a range of skills, people fresh out of college and old hands. Naivety is valuable. To have someone asking what you're doing is good," Nolan says.
XP is taking off in the UK after being around in the US for the past four years, he adds. "Banks have struggled for years with other approaches, which are expensive up-front and don't deliver. With XP, you get a quick return on investment."
Because the code you write is constantly under review, XP makes you a better programmer. "You get closer to the fundamentals of what you're dealing with. Often in large, corporate programming, you are working second hand. If it's delivering what people need, businesses will look for people who have discipline." Nolan predicts people with XP experience will attract a premium.
Connextra started the Extreme Tuesday Club, meeting every week in London. "At the beginning, I met people who were frustrated and wanted to leave software," Mackinnon says. "Now they're getting back to what they enjoy."
To find out more about extreme programming the two key US sites are: www.extremeprogramming. org and www.xprogramming.com. There's a split appearing in the groups and xprogramming.com takes "a tougher, more regimented approach".
The main UK site is www.xpdeveloper.com, with details of Extreme Tuesday meetings. For more information on Connextra, visit connextra.com