In 2001, there was a history-making conference of software-engineering thinkers in Snowbird, Utah. The product of that meeting was a remarkable document called the Agile Manifesto, a call to overturn many of the assumptions of traditional software development. I, in my capacity as one of the principal theoreticians of open-source development, was invited to be at Snowbird, but couldn't make it.
Ever since, though, I've been sensing a growing convergence between agile programming and the open-source movement. I've seen agile concepts and terminology being adopted rapidly and enthusiastically by my colleagues in open-source-land — especially ideas like refactoring, unit testing, and design from stories and personas. From the other side, key agile-movement figures like Kent Beck and Martin Fowler have expressed strong interest in open source both in published works and to me personally. Fowler has gone so far as to include open source on his list of agile-movement schools.
I agree that we belong on that list. But I also agree with Fowler's description of of open source as a style, rather than a process. I think his reservations as to whether open source can be described as just another agile school are well-founded. There is something more complicated and interesting going on here. and I realized when I read Fowler's description of open source that at some point I was going to have to do some hard thinking and writing in an effort to sort it all out.
While doing research for my book The Art of Unix Programming, I read one particular passage in Fowler's Refactoring that finally brought it all home. He writes:
One argument is that refactoring can be an alternative to up-front design. In this scenario, you don't do any design at all. You just code the first approach that comes into your head, get it working, and then refactor it into shape. Actually, this approach can