The Artima Developer Community
Sponsored Link

Leading-Edge Java
Eclipse's Culture of Shipping
A Conversation with Erich Gamma, Part V
by Bill Venners
June 28, 2005

<<  Page 3 of 3

Advertisement

Agile practices in Eclipse development

Bill Venners: What agile practices does the Eclipse team follow?

Erich Gamma: You'll see our agile practices not only in what we do, but often also codified in the tool we build. We support refactoring, unit testing, fear-free development with a local history and tightly integrated versioning, automated build process support with Ant--things like that--directly in Eclipse.

As far as the agile practices we follow when developing Eclipse, we always test early, often, and automated. For each build we run over 20,000 tests. We have nightly builds that are automated. We get build reports that tell us the failures. Recently in 3.1, we added performance tests. So we not only test for correctness, but also for performance. This has helped us a lot during the 3.1 cycle and actually you will notice significant performance improvements in version 3.1.

We practice incremental design. We invest in APIs up front. But we're also improving them incrementally. We refactor, but when we refactor we keep the stability of already published API in mind. We cannot just break clients. We also eat our own dog food daily. Each component exports its latest plug-ins and runs on top of it. This is great because you are the first one to discover your own errors. And of course when you're building an IDE or tool, you're in a deluxe position to do that. Sometimes we deploy more than once a day. So if we introduced a bug in the last two hours we'll often find them even before the daily build kicks in.

Bill Venners: You actually deploy the components to the developers' work stations, and they are using the currently released version for the ongoing development?

Erich Gamma: Yes, exactly. The developers install the latest built versions of their plug-ins and then run with them.

Customer involvement is an agile practice. And mapped to open source, this means community involvement. And we have a very active and large community. The community isn't shy. It makes ambitious requests, but in the end it is highly rewarding and fun to work with such a community.

Another agile practice is continuous integration. We do nightly, weekly, and milestone builds. We also have a notion of build promotion. Nightly builds build the latest code. We use it as an early warning system to uncover integration problems across components. The next promotion level is an integration build: once a week, we want to have something that is good enough for other eclipse committers to use. The next promotion level is the milestone build, which is every six weeks. Here we want to have a build that is not just good enough for us committers, but is good enough for the entire community. So we practice continuous integration with promotion.

We also practice short development cycles. Our development cycles are not as short as XP suggests. As I explained with the bus stop metaphor, we feel we can't go shorter than six-week cycles.

We also do incremental planning with time boxing. Given that we have the six-week cycles, this is our time box. Our top-level plan is also a dynamic plan that is incrementally updated. That is, we don't come up with a final plan up front. We have an initial plan that lists the milestones, the themes and major work items, but we adapt the plan over time. This was also a lesson learned. Originally we had static plans, which meant the plan was accurate when we started, but not later on. We opted to plan as we go, and now the final version of the plan is done the day we ship. All of our planning is done transparently. For each plan item we state whether the item is committed or proposed and we update the status regularly. Therefore the community sees what we have committed to, and what we have proposed. We usually want to hit our target, and if we can't hit it, we are willing to cancel proposed items, but we really hate to drop committed items. Looking back on 3.1 I'm glad to see that this was indeed rare.

Next week

Come back Monday, July 11th for the next installment of this conversation with Erich Gamma. If you'd like to receive a brief weekly email announcing new articles at Artima Developer, please subscribe to the Artima Newsletter.

Talk back!

Have an opinion about the design patterns topics discussed in this article? Discuss this article in the Articles Forum topic, Eclipse's Culture of Shipping.

Resources

[1] Erich Gamma is co-author of Design Patterns: Elements of Reusable Object-Oriented Software, which is available on Amazon.com at:
http://www.amazon.com/exec/obidos/ASIN/0201633612/

[2] Erich Gamma is co-creator of JUnit, the defacto standard Java unit testing tool:
http://www.junit.org/index.htm

[3] Erich Gamma leads the Java development effort for the Eclipse tool platform:
http://www.eclipse.org/

About the author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima Developer. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project, whose ServiceUI API became the de facto standard way to associate user interfaces to Jini services. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community.

<<  Page 3 of 3


Sponsored Links



Google
  Web Artima.com   
Copyright © 1996-2014 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use - Advertise with Us