Day 4: Java in the trenches, the Eclipse Way

Calling Eclipse "One of the most successful software projects in history", John Gage opened JavaOne Day 4 by introducing Eclipse project managers Erich Gamma and John Wiegand.

 

Erich and John begain with a description of what they call "The Eclipse Way", the process that the Eclipse project has used to deliver releases for several years. The talk was similar to one given at EclipseCon earlier this year, but included a demo of some new collaboration technology being developed in the research labs. The rest of this article is a summary of their presentation and demo.

The Eclipse Way is based on certain core values, refined in the trenches by iterating, learning, and improving, at each stage. The key to the Eclipse Way is "rhythm". The rhythm is the heartbeat of a project, making it predictable for both consumers and developers.

The process of creating a new release is broken into three phases: warm up, steady state, and end game.

Warm up

We start by having warm-up phase. This is a recovery time after the last release. We try to schedule this during vacation time. When the developers come back, when they're refreshed and ready, we do retrospectives of the previous cycle, and try to work up an initial release plan. This is just a first pass.

At first we tried static plans but it didn't work so we went into a dynamic plan style. For each feature we mark it as committed, proposed, and deferred. At first, we tried to hold the plan back, afraid to put something out because we weren't sure it was going to happen, planning behind closed doors. So we decided to reflect that this was a proposed item, be transparent, and get feedback early. The plan is revised.

Steady state

Next we go into the steady state of the project, and start cranking out milestone releases at regular intervals. Each milestone has phases of its own, and it's always the same: plan, develop, and stabilize. Through trial and error we found that a milestone length of 6 weeks works out well. We tried shorter cycles (like 2 weeks) but it wasn't enough time to make some real progress.

End game

After we're done with the milestone phase we transition into the end game. The end game is the sprinting point, where we get the quality from "good" to "golden". To get there, we iterate quickly through fix and test cycles, first lookint at the "spit and polish" issues and then limiting changes to only more serious problems.

To keep developers from being fatigued, we amortize the cost over the milestones. In other words, the quality and polish effort is distributed throughout the release. We don't have a seperate testing organization, so developers oscillate between testing and fixing.

During the end game, initially we had one week testing, one week fixing, one week testing, etc.. But that proved to be too tiring for the developers so currently we do about 2 days of test and have a longer fixing pass.

As we move through the release candidates in the end game, we raise the bar on what fixes go in - more reviewers, more approvers, and published fixed lists.

Then comes the point where you're really getting ready. There is a collective signoff, which gives everybody on the team a feeling of shared responsibility and committment. We do GO/NO-GO decisions at each milestone. It's not just a formalism.

More lessons from the Eclipse Way

- Have healthy milestones. We hear many people say they do milestones, that they do iterations, but it's hard. A sign of a healthy milestone is it's consumable (tested, demoable) and honest (time-boxed, bottom-up). Since we, the developers and project leaders, are the ones doing the milestones we're acccountable for the committment.

The fact you don't need to think about how the milestone week works is worth a lot. Everybody knows what to expect. The other thing we can do is adjust where we're going. Where did we over- or under- achieve? We can take that into account and tweak the goals for the next milestone.

- Be open and transparent. We do continuous integration, in public, with a fully automated build process. We have daily builds, integration builds, and milestone builds. Integration builds have to be 'green', i.e., they have a certain level of quality.

- Always be shippable. Another emportant feedback mechanism is what we call "live betas". To do this you have to be continuously consumable. To make it appealing it has to be continuously interesting. And on our end we have to be continuously listening. The key is to get users excited.

- Use your own stuff. The component teams are using their own code on a daily basis. At a weekly basis, the whole project team is adopting the latest sets of changes (weekly integration builds). Then we transition to the milestone and involve the whole community.

- Engage the community. The users have to feel the milestone as well. We publish new and noteworthy documents, and our community picks it up and blogs about it. That's all the "marketing" behind it. Before we did the new and noteworthy, nobody knew what was there, so they didn't try it out. New capability in each milestone gives reasons for people to adopt and provide feedback.

Next generation tools: Project Jazz

We're tool builders, and we want to become even better. How does this impact the next generation of tools we're building? Our focus for more than a year has shifted to think about team productivity improvements. What can we do to make us even more effective here?

"Jazz" is the code name for a commercial product, a joint effort between IBM Rational and IBM Research. It's a team collaboration platform. Jazz provides tooling support for all the practices we talked about such as milestones, continuous integration, end game, etc.. You can look forward in time with the plan, or backward to team events (such as which bugs got fixed when). Team awareness and transparency is built in. So is build awareness, for example looking at successful and failed builds, searching for stack traces in existing bug reports, and running tests locally.

As you fix the bugs you build up a highly linked structure that lets you connect all the artifacts and understand what's going on. And as you get into your end game, you can apply rules that raise the bar on changes. For example, you could say that you can only work on a bug that your component lead has assigned to you. Project health is assessed and graphed using a variety of metrics.

Demo: Sneak peek of Jazz. For more complicated scenarios come to the Jazz BOF tonight.

Take-away quote: "Make things visible, even if they're not pleasant" - Erich Gamma