email article printer friendly

Eclipse as Framework and Way of Life
IBM Rational Software says rhythm leads to good health.
by Peggy Aycinena

JavaOne, May 2006

Two guys and 20 combined years of commercial and open-source software development were up to the task, at the 2006 JavaOne Conference, of detailing IBM's Eclipse development initiative, how it's organized, managed, and clearly inspiring other companies and organizations to mimic the IBM philosophy.

Eclipse is an open-source framework, initially launched by IBM, that's being used—among other things—to implement a Java IDE and to provide support for other rich-client applications, such as modeling, testing & performance tools (the TPTP project), and business intelligence & reporting tools (the BIRT project).

Erich Gamma and John Wiegand detail IBM's Eclipse development initiative.

The Eclipse open-source community is a lively one, supported by a number of big players in the software industry, and responsible for the ongoing development and maintenance of the platform. It’s a group that prides itself on the "vendor-neutral" nature of its efforts—hence, the magnitude of the shadow the Eclipse framework throws across the software landscape.

Not surprisingly then, IBM Rational Software Distinguished Engineers Erich Gamma and John Wiegand had a thousand, or more, JavaOne attendees eating out of their hands in the main auditorium at Moscone Center in San Francisco as they cheerfully laid out, tag-team style, the ongoing IBM Eclipse development process in a fascinating, even captivating, hour.

Wiegand told his audience, "We want to talk to you about what works and what doesn't work. We think our story will resonate with you—looking at the process from the inside and how we develop Eclipse, which practices we're using, and our reflections on how it impacts the tools and the flows."

Gamma got a big laugh when he added, "We had a late start at IBM. When we first talked about our Eclipse project at JavaOne in 2002, not only did we not make it here to the main stage, we had to escape to a nearby bar to do our demo for people who joined us there."

So what's the difference between then and now? Gamma said it's very simple, "Shipping software—over an extended period of time. Ship, ship, ship! That's the simple story."

Wiegand agreed shipping was important, as well as development tools and methodologies, but overall he said, "It's the people and the team. We've got a globally distributed team in North America, Europe, a small group in Australia, plus other global contributors…and these people are at the centerpiece of [our success]. People coming together, working together, and caring about what happens is what makes the difference."

Gamma quoted the Agile Manifesto, "People and interaction always over processes and tools." He admitted that he'd never thought at an earlier point in his career that he would be putting this kind of emphasis on the human element. But his work on Eclipse has caused his viewpoint to mature, he said.

Wiegand added, "Predictability, transparency, feedback, commitment to community, and consuming your own output," complete the list of values that he and his group successfully mastered in advance of establishing the practices embedded in the IBM Eclipse effort.

Then, Wiegand and Gamma got down to the nuts and bolts of the process. They said that it's all about rhythm; the team has a 12-month rhythm, a six-week rhythm, and a five-day rhythm. Hence, team members know what they will be doing and how to plan their work well in advance of each phase of the process.

The 12-month rhythm starts with a month of downtime—a warm-up phase—following each annual release, when team members recharge their batteries and renew themselves for the coming year's efforts. That's followed by a brief period of retrospection, where the team evaluates what worked and what didn't work over the previous year.

The six-week rhythm is about testing and implementing fixes to produce "mini-milestones" of progress towards the major annual release. Wiegand and Gamma reported that if the test-and-fix cycle is any longer than six weeks at a stretch, team members grow weary, "developer fatigue" sets in, and the effectiveness and accuracy of the work decreases.

The five-day rhythm is part of the sixth and final week of each six-week rhythm, just prior to each mini-milestone release. It consists of a series of tasks, carefully assigned to each day of that week—Monday is warm-up, Tuesday is validate, Wednesday is test, Thursday is fix, and Friday is verify—where reasonable and rigorous reviews take place. "The success of our team has been built around early incremental planning," Wiegand said.  He added that sticking to those plans is crucial.