Q&A with Jolt Product Excellence Award Winner Paul Duvall
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Q: Congratulations on your Jolt Award for the technical books category! How and when did you get the inspiration to write Continuous Integration?
A: Thank you very much. The inspiration for the book was many years in the making. On one of the my first projects I developed common components and utilities for other software developers. On this project, I really became interested in how to not just make my life easier as a developer, but make my fellow software developers' jobs less painful as well. It was also on this project that I hung the "Integrate Button" picture in my cube - which served as the theme of Continuous Integration. I really thrive on the tenets of repeatability and consistency and, as developers, I believe we spend too much time on development infrastructure issues such as setting up IDEs, defining a consistent build process, hunting down server configuration values and other such things. Since we spend a lot of time automating our customer's process, why don't we automate our own development processes? This philosophy led me into positions where I was the developer/build guy or tech lead/build guy. I also like to share my ideas with others; I've always thought that if I find an easier way to do something, I'd like everyone else to learn from these experiences. I believe that if you keep knowledge locked inside your head, without sharing with others, you are a less valuable resource. So, it was natural that as my passion for automating development processes (using practices like CI) grew, I wanted to share it with others. This is one of the main reasons why I wrote the book. I began to cultivate the idea of writing this book while on a train from Rome to Florence, Italy in the summer of 2004 while on vacation with my brother. A lot has changed since then!
Q: Since the publication of Continuous Integration, what type of feedback have you received from the software engineering community?
A: Most people I hear from say to me time and time again that this book was long overdue as it's a core Agile practice. I also hear from people that were able to incorporate a lot of the practices we cover in the book on their projects which is particularly gratifying.
Q: Is it fair to say that the practice of CI is an emerging trend?
A: No question. It's one of the least controversial of the Agile practices, but it's still not in what I consider to be widespread use. CI provides teams a way to quickly determine the health of the software; it shrinks the time between when a defect is introduced and when it's fixed, which reduces costs. It's also an emerging trend because there's so much more we can do, particularly in what a "build" can provide. A build is much more than compilation and packaging. It's database integration, testing, inspections, deployment and even installations. A build is integrating all of the components and verifying the deployed software works as a whole.
Q: What does the future hold for CI, and why are you excited about it?
A: I see the future of CI is getting to production-ready software every day. I think that as we increase hardware and software resources, we can get closer to achieving this in reality. Regardless, if development teams regularly consider what it'd take to make their software "production-ready," their approach to developing software will change significantly. The reason I like the concept of "production-ready...every day" is that it speaks to development teams and customers in the same breath. Whether or not you actually deliver software every day is irrelevant; being production-ready enables you to make ongoing project decisions based on the reality of a working software system, not what teams intend on completing. It also logically leads teams to consider practices such as test-driven development, automating deployments, and failing builds based on thresholds such as a high cyclomatic complexity. No longer can you say "I'll get to that later."
I'm also excited to see the practice of CI move toward instantaneous integration where the type of full-featured integration I described is built into the tools so that it truly is a 'non-event' to integrate software. At a recent Agile event, I heard someone describing a scenario in which a developer types a line of code, the line is marked in red in their IDE — because it integrated that line change (in a separate environment invisible to the developer) with the rest of the developers on the project and determined that the recent change broke a call to a method that another developer had recently changed. This is the future of CI that I envision.
Q: What is the most valuable piece of advice you can offer to an organization that is investigating CI?
A: Continuous Integration is not about the Continuous Integration server. It's about development practices and — at a technical level — the automated build. The fact you can run it as a daemon/service is one way to make CI continuous, but it's such a small part of CI. I often hear teams talk in terms of their CI/build management server like it's the one doing all the work. It's not. It only provides a mechanism for kicking off a build and telling you what happened (in terms of reports, emails, etc.). Committing code often, preventing broken builds, fixing builds quickly, running fast builds: these are all effective practices toward getting the most from Continuous Integration.
Q: What does it feel like for the book to have won the prestigious Jolt Award?
A: It's been a great thrill to win the award. It was an honor to even be selected as a finalist, especially in such great company of the other finalists in the technical book category. So, winning the Jolt is just icing on the cake. It really validates all the time and effort I expended working on the book. I remember sitting in a Starbucks at 8:00pm on a Saturday evening, taking off days from work, renting a hotel in Charlottesville, Virginia for a week and even editing my manuscript while on vacation in the Outer Banks, North Carolina. I lived and breathed the book for a couple of years and it feels incredible that an elite group of Jolt judges selected my book as the winner of this award. It's very, very gratifying.
Q: Tell us more about your company, Stelligent.
A: Stelligent is an expert Agile consultancy. We help our customers create production-ready software every day. We do this through a combination of Agile techniques and practices such as Continuous Integration, Test-Driven Development, Pairing and so on. One of our key differentiators is that we don't just talk about these things, we roll up our sleeves and work with clients to deliver real solutions. We have a very practical, non-dogmatic approach toward improving our customer's ability to deliver high-quality software quickly. Stelligent is led by people like Andy Glover, co-author of Continuous Integration, and Paul Julius, co-founder of the CruiseControl CI server and Continuous Integration and Testing Conference. We share a similar passion for helping development organizations become more Agile.
Q: You once wrote a blog entry entitled, "Fire your 'best' people, reward the 'lazy' ones." Can you elaborate on what you meant, and discuss the controversy that this statement caused?
A: I know, it's a bit of a provocative title! It was based on the observation at several companies that some managers consider their best people to be the ones who can get them out of a technical jam: the "firefighter." This firefighter may stay late to fix the problem and be the hero. Sometimes, however, if you peel back the covers you'll discover that there is no time spent in preventing the problem from occurring again and that it could've been the firefighter to cause the problem in the first place. In the blog, I indicate that you need a little of both, someone that can fix problems (because problems will always occur) and prevent problems. I refer to the troublepreventer as someone who is lazy, but in a good way. Someone that doesn't like to be awakened at three in the morning to fix the latest problem because someone hard-coded a variable or duplicated code which led to a software error only a few know how to fix. I think the reason for the controversy is because some inferred that I was stating that someone must be either a troubleshooter or a troublepreventer, not both. As I describe in the blog, there should be a mixture of both...but, I believe we need more people that employ troubleprevention techniques.