Shane Warden is co-author of "The Art of Agile Development" and author of the Extreme Programming Pocket Guide (and others, going by the name "chromatic").
Q1- My first question is the same as I asked Jim, I'm really enjoying your book. I honestly think it is the best agile book I've read - and I've read a good few of them. Good job! Can you tell me a bit about yourself - both personally and professionally? What got you to the point where you could produce such a wonderful book?
Like Jim, I started programming when I was very young. I must have been six or seven years old when I saw my first minicomputer, and I sat down, opened the manual, and typed the first program I came to. (For some reason I ignored the line numbers in the book and typed the program directly, which didn't exactly work. I suppose some of us learn to debug early.)
For a long time, nothing happened. My undergraduate degree is in music, but I realized that I wanted something with more stable job prospects, so I returned to technology after I graduated.
During a stint as a system administrator as the dot com era heated up, I rediscovered programming and spent a lot of time reading the source code of free software projects, trying to improve my skills and discovering that successful projects had development processes very different from those I was seeing in our corporate IT group. When I read the first XP book, I realized that there were important commonalities I'd seen in both, as well as practices that were missing (in particular, refactoring and test-driven development).
Through the next phase of my career (consultant, writer, software developer) I continued to explore the ideas of agility especially as they related to software quality. I wrote a lot of tests, test frameworks, test tutorials, and testing advice, and I started to see how adopting even just one or two practices improved software development. I also saw first-hand how adopting just one or two practices without considering their context made it difficult to succeed in software development. (In particular, the lack of stakeholder support can doom almost any project.)
I wrote the XP Pocket Guide for O'Reilly, and in the year of research and writing (and admittedly arguing with Jim occasionally about how strict or lenient to be and how people were likely to pick and choose what they wanted to do) I really understood how everything fit together. If you look at the Art of Agile Development, you'll notice that almost every practice we discuss has one or more contraindications. Sometimes you really can't practice the practice precisely the way we recommend, and that's fine -- but you need something besides a tremendous amount of luck to fill in the gaps left behind.
Comments