Sponsored Link •
Erich Gamma lept onto the software world stage in 1995 as co-author of the best-selling book Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley, 1995) . This landmark work, often referred to as the Gang of Four (GoF) book, cataloged 23 specific solutions to common design problems. In 1998, he teamed up with Kent Beck to produce JUnit , the de facto unit testing tool in the Java community. Gamma currently is an IBM Distinguished Engineer at IBM's Object Technology International (OTI) lab in Zurich, Switzerland. He provides leadership in the Eclipse community, and is responsible for the Java development effort for the Eclipse platform .
On October 27, 2004, Bill Venners met with Erich Gamma at the OOPSLA conference in Vancouver, Canada. In this interview, which is being published in multiple installments in Leading-Edge Java on Artima Developer, Gamma gives insights into software design and development. Unlike the other articles in this series, this interview installment is based on a phone interview that took place on June 16th, 2005, shortly before Eclipse version 3.1 was released.
Bill Venners: How long have you been involved with the Eclipse project, and what are the most significant lessons you feel you and the Eclipse team have learned about the development process through that experience?
Erich Gamma: I've been with Eclipse since the beginning. It is actually difficult to give a fixed starting date, because there were some projects that were naturally evolving into Eclipse. For example, I had already been working on the Visual Age Micro Edition integrated development environment. Some components started in this project and were continuously refined and became a part of Eclipse. It was also during this project that SWT was born. I guess it's been about six years.
When the Eclipse project began, OTI had a culture that focused on shipping on time which has always put people in the center of the development process. Since then I've been amongst others working with John Wiegand tweaking the way we develop. During the past six years we have continually adapted. We tried out things. The things that didn't work we stopped doing and things that worked we kept on doing. And, our teams made it all work.
One thing we learned was the importance of teasing out continuous deliverables. Initially we didn't have that. As a consequence we had stressful finish sprints towards the end of a release cycle. Now we have short delivery intervals. Every six weeks is a milestone. This is something we evolved to, and now we are moving to a model of always striving to be ready to ship—we always want to be in beta.
Since we are open source, we also learned the importance of the feedback loop with the community. It is vital to interact with the community and to be transparent so the community can participate. We have achieved a good transparency level, but we are still continuously striving to improve and involve the community even more. It's obvious, isn't it, that you get a better end result with more community involvement?
Bill Venners: It seems like there's a culture of shipping that you value.
Erich Gamma: That's right. In software, having cool ideas is nice, but shipping them is what counts. For us it only counts if you have shipped the thing. That's really the mindset we have. And given that you focus on shipping, we never want to be in a mode of always being two years away from shipping. You need to have a short-term deliverable. You also plan, decide and act with this mindset. You are very risk- aware— you know what you can do so you can still ship on time with quality.