“I’d always been a technically focused person,” says the Oregon-based developer, who was in Auckland last week for a two-day conference on the XP methodology. “Then I visited an investment bank and saw a tinpot dictator bullying his technical staff. I was absolutely furious at how this son-of-a-bitch was treating these programmers.”
Beck says the team was doing poorly, but instead of blaming the programmers the boss should have been looking for better ways to manage the project.
A few years later he was called in to fix a failing payroll development at car maker Chrysler. To get the project back on track Beck took what he knew were good practices in software engineering and carried them to extremes, while assuming all others were overheads and ignoring them.
“I took everything I knew and cranked all the knobs up to 10. Testing is a good idea so we tested all the time. Talking to customers is good so we had them sitting in the same room as the programmers. Design is good so we spent time on design every day. That was the initial premise and it’s the sense of ‘extreme’ in extreme programming.”
In 1996 Beck brought 12 core practices together and coined the term.
Under the practice known as “the planning game”, business people write desired features on index cards known as “user stories”. The development team estimates how much effort each story will take and how long it will take to produce. Business then decides which stories to implement in what order.
“That’s not the end of the conversation, it’s the beginning,” says Beck. “Business people are responsible for scope. If a feature’s not there it’s because business didn’t want it. If you write a spec at the beginning you’re tempted to push everything into it, but if you have ongoing dialogue you align business and technology.”
Beck even uses the approach in everyday life. “Anytime I have too much to do I write everything on index cards, assign the cards weights, estimate what should get done based on weights, and then choose.”
Other practices include “small releases”, whereby companies start with the smallest useful feature set and release early and often, adding a few features each time, and the “40-hour work week”, which means programmers go home on time. In crunch time up to a week of overtime is allowed, but consecutive weeks of overtime are a sign that something is wrong.
“The industrial revolution set up this management/labour conflict which has been unconsciously adopted in software development,” says Beck. “The goal of XP is to slice projects very thinly so we specify, estimate and deliver something concrete on a regular and ongoing basis. Management is happy to see ongoing progress and you create a virtuous spiral.”
Over the past five years extreme programming has steadily gained acceptance around the world despite the fact that it can cause upheaval at work when introduced, he says.
“People have to learn new skills, which isn’t easy, but over-riding everything are the questions: Is the software going to be better if the customer sits with the team? And is it worth it? If not, don’t do it,” says Beck.
Beck says projects best suited to XP are those with small teams, rapid release cycles, and rapid and violently changing requirements. It is also more suited to object-oriented programming languages.