At the Agile 2011 we celebrated the 10th anniversary of the Agile Manifesto. To further celebrate, I decided to re-publish abbreviated versions of my interviews with several of the 17 authors. These interviews were published in my 2002 book, Agile Software Development Ecosystems. They reflect the state of the industry and what these founders of the Agile movement were thinking a decade ago. I’ll continue with Martin Fowler.
Martin Fowler holds the position of chief scientist at ThoughtWorks. He and I shared a pint at the Lodge Bistro lounge at Snowbird after an afternoon of shushing down the slopes. Trying to have a “serious” talk over the music and the growing après ski crowd was a challenge, but we managed to bear up.
Jim: What was the evolution in your career that brought you to ThoughtWorks, refactoring, and your work with XP?
Martin: I work for Coopers and Lybrand and Ptech in the UK before coming to the US in 1994. Here I continued working as an independent consultant, but prior to that, at OOPSLA in 1992, I listened to a talk by Dave Thomas who made a somewhat offhand remark that every object should test itself. It set a little jingling in my head: “Oh, that’s an interesting idea.” So in my own work I started writing tests for every class, and I found it made a profound difference.
Jim: Didn’t you get involved in the Chrysler C3 project around this time?
Martin: Yes, around 1993 they wanted to replace the creaking, old payroll system. I led a modeling effort for them, and I still feel that a lot of the ideas that ended up in C3 were born during some of these sessions. Chrysler contracted with Good Object Programmers, Inc. [a fictitious name] to do the development work, and it was a complete disaster from the start. They then brought Kent, initially at least, to work on performance issues.
Kent’s statement of work was wonderful; it said, “Come in and help us with our performance problems, but if there’s anything else you’d like to chip in while you’re here, make sure you do so—comment on the design, etc.”
And, of course, Kent completely exploded the project and ended up taking it over. This is now the C3 project that everyone talks about. They threw away a lot of code. Started from scratch—well, it wasn’t really from scratch because of the fact that they had already built the system once. The developers learned a lot from that experience, so it wasn’t as if they started from a clean sheet of paper.
I was invited back to the project. Lots of things about this new project were really wonderful. The planning was really good. It was basically the way it’s described in the green book. The plan was always believable. You looked at the plan and thought, “Yeah, that’s what it is. It may not be much, but that’s what it is.” It was the best plan I’d ever run into. I was also very impressed by the testing. One of the things that made me comfortable with Kent taking the project over was when he said that testing was one of his primary things.
The C3 project struck me as very controlled, very disciplined—but at the same time very flexible and I really liked what Kent had done.
Jim: What about your work at ThoughtWorks?
Martin: I’ve been pushing for Agile, lightweight processes—sometimes XP, sometimes others. To me, XP is one instance of an adaptive process. I expect that we will end up with a number of these methodologies with overlapping boundary conditions. We will need to choose which one best matches our profile. We’ll start with one of these then rapidly tune it to a particular circumstance. Certainly, anything you pick will only be a starting point and then you tune it to what you need it to be. Methodologies can also give you good practice ideas.
The other thing I really learned from XP was the way in which techniques interact with each other. Before, I was in favor of best practices, but what I learned from Kent was that you can’t choose the practices in isolation; you have to see how they fit with the others.
Jim: What are things about Agile methodologies that you like?
Martin: I think the basics are very easy. In my “New Methodology” paper, the two key things I picked out were adaptive and people orientation—two critical things. Now adaptive grows into self-adaptive, which is the process changing itself. It sort of flows—if you have an adaptive process and you are people oriented, you have to be self-adaptive. Lighter methodologies de-emphasize stuff. It’s better to start with something small and accurate. Look at RUP. It has tons of really good stuff in it, but you’ve got to figure out which bit of stuff you want.
Jim: I like that about XP also, a good, well-defined set of complementary practices—as some have said, a system of practices. I think both philosophy and practices are important. Why do you think XP has gained such notoriety?
Martin: Kent also has a way of shocking people. I’ve described XP as a cattle prod to methodologists. Somehow Kent managed to create a shock effect. The second thing is Kent really managed to create a gathering around him.
Jim: How much does the success of XP and other Agile methodologies come from working together, from the collaboration?
Martin: Collaboration is key. I mean, Kent makes the comment that communication is the key bottleneck in software development, and he’s not joking. It’s absolutely embedded in XP—people oriented as opposed to process oriented. You look at the people and then make the process fit them. You recognize people are human beings and they are also the most important factor in whether you succeed or not.
Jim: What is your vision for the future and your part in it?
Martin: In a way, I’m not very interested in methodology. I’m not a methodologist; I try to resist it. My interest is in what kind of design works. What makes a good design? How do you recognize good design and what do you do with it? I’m very conscious that process has an effect on design, often a stifling effect. I basically want it to get out of the way and let the individuals excel—that’s why the people-oriented idea really makes a difference to me.
Jim: I’ve been talking about the difference—often not recognized—between the terms “formality” and “discipline.” You can have a highly disciplined group that’s just not very formal—which is how I perceive XP. Given a choice, I’ll take discipline over formality every time.
Martin: The point is fundamentally that human beings, developers, are not stupid—they are not going to do something that doesn’t seem to be adding value. For example, up-front testing doesn’t seem to be adding value until you make a big change and the problems pop right out. You get into this rhythm of writing tests first, but you’ve got to get over the initial hump of proving to yourself that it’s worthwhile. The discipline is necessary while you’re getting over the hump, then it isn’t needed as much because you’re going to do it. The problem with heavy process is that they throw all this stuff at you, and you couldn’t figure out the benefit—at least any I could ever see.
This reminds me about what inspired the paper I wrote, “Is Design Dead?” I was having a conversation with a well-known industry person, and he was saying how much he hated XP. He said that the XP white book was the most dangerous book published in the last ten years. I began exploring that statement with questions like, “Do you believe in iterative development?” To point after point, he agreed with the principle. I remember wondering what the difference was. Then it came out. He said, “I can’t have programmers monkeying around with my design.”
As I think about my conversations with Martin, Bob, Ken, Kent and the others, several thoughts prevail. These notable individuals have rich backgrounds in software work and have thought deeply about development practices—most for 10 to 20 years. Their path to Agile methods didn’t start in 1997 or 1998, but from years and years of work—from successes, and failures. One of my goals in publishing these interviews is to show that Agile methodologies aren’t a fad, but the result of years of careful thought and experimentation.