Interview Architecture is sometimes seen as the Achilles heel of eXtreme Programming (XP), but Kent Beck disagrees.

OK, so all those pair programmers produce lots of good functionality for small systems, the sort you can describe on a few library cards; but how can you be sure it all hangs together for something big and complicated?

A little personal history: I've worked on big systems where a strong architecture (in one case, based around a bank's customer database and security subsystem) was the salvation of the business system and enabled it to move forward effectively as technology changed – but I've also worked where "architecture" belonged to the consultants and their PowerPoint presentations, and had precious little to do with what the programming teams did, day-to-day.

So, when I met Extreme Programming guru Kent Beck recently (he was speaking in London in his role as an Agitar Fellow), I asked him about architecture; and we continued the conversation by email. I've been known to suggest that Beck and others of his ilk think automatically in architectural terms. But us mere mortals need formal architectures to work within; otherwise it will All Go Horribly Wrong. Kent responds rather more positively:

"My experience with architecture shapes the architecture strategy in XP," he says. "I repeatedly ran into architectures that were developed up-front, without feedback, and by groups which didn't have to live with the day-by-day consequences of their decisions. What I observed about successful architectures was that they were grown little-by-little."

He talks about authors being almost apologetic about this process, people saying things like: "Well, we couldn't have foreseen that the website would grow this big, so we had to make it up as we went along." But these were the architectures that actually supported his programming efforts. The lesson he draws from this is that effective architectures are "grown", at least for technically challenging situations. The process of building architecture should have lots of feedback built in and it should be kept simple, because extra elements in the architecture introduce instability and unpredictability. The big difference from current practice is that: "I would stop apologizing for architecting this way," he says.

XPialidocious

But there are consequences, whatever you do. You won't get a perfect architecture straight away like this. You may build two or three applications before you work out what the architecture should be – and living with a less good architecture for a while will increase cost and complexity.

However, Kent claims that "the cost of incrementally investing in architectures is more than made up for by reducing time-to-market, increasing feedback, and reducing wasted effort". This seems fair enough to - so long as you are the sort of mature organisation that has some idea of what development costs and how much effort is being wasted (XP has practices to help you monitor this, of course).

It's also quite likely that some cultures will spurn this approach – in fact, Kent thinks this may be a serious challenge to the adoption of XP, especially in the early stages. Your best bet is to go XP in dangerous situations, when things are going wrong – as Kent says, "people are willing to re-think their values if they are in imminent danger of failing". And XP often challenges conventional wisdom.

Then there are the social aspects of XP – It is perhaps significant that Cynthia Andres, Beck's co-author on the second edition of his book Extreme Programming Explained: Embrace Change, is a psychologist and expert on organisational behaviour, decision analysis and woman's studies. "Programmers who glory in individual heroics don't fit well with XP's team ethos", Beck says. But, he notes that it is demoralising to put heart and soul into a failing team. Given a little time to see results, even new XP teams can demonstrate that they will consistently deliver new functionality, week after week – and being part of that is more fun than being alone, at least for most people, he argues.

We didn't discuss the possible hard side of XP, something that exercises David Putman, Agile software development specialist and Application Development Advisor columnist. According to Putman, Agile methods, including XP, are people-focused – but, sometimes, people who won't adapt to the Agile culture, they become a disruptive influence; and you have to let them go, for the health of the team.

And what of eXtreme Programming eXplained, the book? It should probably have been called eXtreme Programming Refactored. It seems to be a rewrite, based on Kent's experiences with XP over the last five years or so; and is now both rather more "extreme" (in the sense of being purist "best practice") and also rather more tolerant of different ways of being Agile.

As Kent says, critics of the first edition complained that it tried to make them program in a certain way; in the second edition he simply presents "proven practices you can add to your bag of tricks". Many, and possibly all, of these XP practices are here to stay, even in architecture-focused organisations – although the nature of XP means that new eXtreme Practices will emerge, probably along with a book eXtreme Programming Even More eXplained. ®

Extreme Programming Explained: Embrace Change by Kent Beck with Cynthia Andres (foreword by Erich Gamma), 2nd Edition, 2004, Addison-Wesley, ISBN 0-321-27865-8