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 2 of 3  >>


Continuous deliverables

Bill Venners: How do you accomplish continuous deliverables in the Eclipse project?

Erich Gamma: We split the release cycle into milestones at a granularity of six weeks, and each milestone ends with an improved and useable Eclipse build. In general, those six weeks are like a small development cycle, in which we plan, develop, and test. With this kind of fractal major plan, we get in effect several small development cycles for each release. We slow down at the end of each milestone. We have a day where everybody gets out of the water and does testing. Doing testing for each milestone avoids that we accumulate a larger testing effort until the end of the release cycle. Then we document what's new and noteworthy, and we announce it to the community so they can observe our progress and provide early feedback. Then we plan the next milestone, taking into account both the overall plan and individual component plans.

So we always want to be in beta. In particular, we don't want to go dark, where people can't see what we're doing for months. The goal is to have our community tracking our progress and providing continuous feedback.

Bill Venners: Why is it valuable to have the community track your progress? Is transparent development something more appropriate to open source, or is it something you think closed source projects can also find beneficial?

Erich Gamma: I think this is independent of open or closed-source. Software creates communities and transparent development is important if you want to grow a community. Open source in particular, though, is not just about making source available under some license; it is really about building up a community. And you build a community by showing them what you're up to, which means you make your plans visible. All of our milestone plans and project plans are visible on the web. All of our bugs are visible. The community really sees what's going on. Of course, what we hope for in return is that the community participates. And participation can come in many different forms—for example providing feedback in bug reports, contributing newsgroup replies, providing patches, implementing additional plug-ins, or writing articles. These are the ingredients of a tight feedback loop, and this kind of feedback loop is the key to having a good, shippable product in the end. The fact that Eclipse has such an active community is really cool and a major asset. Having such a community is an asset no matter whether the environment is open-source or closed.

Bill Venners: You said you plan, you execute, and you test. How long do you plan at the beginning of one of the six-week mini-development cycles?

Erich Gamma: We usually try to have our milestone plan posted after one week. The last week in a cycle is the "chill down." Typically we do a candidate build on Tuesday, testing on Wednesday, fixing critical bugs on Thursday, and declaring the milestone build on Friday. To declare a milestone build each component team needs to say, "Yes, my component is good to go." If there are still problems with a build the component requests an additional build.

It's kind of like driving a bus, and figuring out how many bus stops you should make. If you make too many bus stops, then all that starting and stopping slows you down. That's how we came to six weeks. We need one week to get the plans done, and we need a little more than half a week to stop.

Bill Venners: And that gives you four weeks of execution.

Erich Gamma: Yes, it gives us at least four weeks of execution, which is enough time to do something significant. You have to be able to solve bigger problems in one cycle. We started with four-week cycles, but found the starting and stopping in a four- week cycle was too much overhead.

Bill Venners: Do you have any decompression time built in between these iterations?

Erich Gamma: After we ship a major release, we have around one month of decompression time. We deliver our releases usually in June or July, before people take their vacations. We then have some planned decompression time where we look back and reflect on what worked, what didn't, and what should improve. This is also the time for exploring new stuff. We then transition into thinking about the next release.

Bill Venners: Is there a mini-decompression time at the beginning of each one of the mini-release cycles?

Erich Gamma: You need decompression time when you have really been compressed, but the idea of the milestone releases is to not be continuously compressed. Rather, we want a regular rhythm of sustained development. We start. We stop. At the end before we ship an actual—not milestone—release, then we have some compression. This is the end game, which is intense. We have to do testing and very careful fixing to address last-minute polish or performance items. We know we can only do this for a certain amount of time. The end game is tiring, and afterwards, you need decompression, because everyone has to do a lot of compressed development towards the end.

Bill Venners: What's the end game?

Erich Gamma: The end game is the last six weeks. We have milestone, milestone, milestone, milestone, then basically the last milestone is the end game. It is usually also six weeks. In the end game we want to have convergence. We want to stabilize and move forward carefully. These six weeks are planned in detail and the end game plan is published on the web. The end game plan defines a rhythm of test, fix, test, fix, test, fix. The whole team, supported by the community does that. All the developers and the community test for two to three days, then we fix for four or five days. We test again for two or three days. And, with each fix pass, the rules become tougher for getting changes in. In other words, the later in the end game, the harder it is to get a change in. For example, for a bug to be fixed it needs to be posted to the developer mailing list and the fixes need to be peer-reviewed.

What can also be stressful in the end game is that sometimes we have ripples that have to percolate up the higher layers. We really prefer to work on planned things, but during the end game it is difficult to plan everything.

Bill Venners: What kind of ripples?

Erich Gamma: For example, we find that a lower layer has added a new mechanism that isn't leveraged yet in all the upper layers. These kinds of ripples are difficult to plan. An upper layer might have jumped on a new function and a lower layer thinks they are already done.

Bill Venners: That sounds like a communication issue. The people who are doing the lower layers need to communicate better with the people doing the upper layers.

Erich Gamma: Absolutely, I mention it to show that even after shipping on-time for several years we're not perfect. The best solution we've found is where the lower layers help to carry forward the required changes by providing patches and help to the upper layers. The mindset we're trying to foster is that you are not done with a feature before it has rippled through all the layers.

<<  Page 2 of 3  >>

Sponsored Links

Copyright © 1996-2018 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use