Eclipse as Framework and Way of Life

IBM Rational Software says rhythm leads to good health.

• By Peggy Aycinena
• May 1, 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).

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.

Gamma reiterated, "The key theme throughout our process is rhythm. That's the heartbeat of the process, and a set of practices that get us into a healthy state of mind to make continuous progress towards our milestones."

Wiegand said that a healthy state of mind, and of project, rests on one additional, important concept: "We always need to remember that software is never perfect. But continuous and transparent planning, with lots of early feedback, [can create realistic expectations] on any project."

Both Gamma and Wiegand said that the IBM Eclipse team learned from their early experiences working behind closed doors. They agreed that having an open and honest plan, today, and giving users continuous updates along the way, is a far superior strategy for achieving success.

Erich Gamma, IBM Rational Software Distinguished Engineer		John Wiegand, IBM Rational Software Distinguished Engineer

Gamma said, "A healthy milestone [schedule] means that you don't suffer from the 'hanging rope' syndrome," a reference to projects that start slowly, and increase efforts and speed in the second half, unhappily sprinting to a stress-filled finish at the end. "The whole point of having rhythm is to prevent that [situation]," he said.

Wiegand said, "Now, everyone knows what to expect and we're all effective. We can see what we've achieved, or underachieved, and we [have a way] to adjust where we're going."

Organizationally, everything Gamma and Wiegand offered was not only intuitively satisfying, but undoubtedly also enviable for the many in the audience who might be struggling under a less organized management style.

However, it was when the two engineers—using the systems on stage, monitor images projected on the big screens throughout the hall for all to see—walked through their file structures and project management schemas, that they proved they'd executed on their philosophies.

IBM Eclipse team members around the globe are in constant communication through a complex project management application, and a highly detailed set of revision control checkpoints. Reporting capabilities and bug-tracking record keeping are also sophisticated and clearly displayed—build pages and gate keeping for the project, carefully monitored and managed.

Gamma summarized the effects of the management tools. "The product and process are continuously consumable, continuously interesting, continuously listening, there are continuous demos, continuous feedback, and continuous learning, [which] lead to continuous health. And, users have influence!" He earned a round of applause for the organizational beauty of these tools.

Wiegand and Gamma spent the next few minutes praising the benefits of community feedback, and the responsibility they feel, along with their team, to honor and incorporate that feedback. Wiegand said, "We publish new and noteworthy documents [on a regular basis], and thanks to our community, they pick it up and blog about it," Wiegand said.

Gamma concluded, "To get quality to go from good to gold, the endgame [has to be] about rhythm. Test, fix, spit, and polish. It's what we do to get there."

Wiegand had the last word. He talked about something best described as pride of ownership, and referenced the disdain with which real estate riddled with broken windows is treated: "We want to avoid broken glass [in our project]. That includes code bloat, software rot, and bug pile-up. Once you have commitments [to your clients], and you work with your customers to keep them productive, there's stability there. It's about getting healthy and staying healthy, [and] iterating and delivering a package—a 'house' that people treat with respect."

At the end of the presentation, the JavaOne conference host, Sun Chief Scientist John Gage, leaped back up on stage to congratulate Gamma, Wiegand, and the entire IBM Rational Eclipse team on the completeness of their message.

Gage expressed hope that their discipline and structure might be imported into the national school systems to enhance educational effectiveness in the U.S. He noted that the mindsets of team awareness, transparency, iteration, and integration to move forward toward achieving goals is applicable across a wide variety of disciplines. Hearty closing applause indicated the huge audience agreed with Gage, and endorsed his endorsement.

About the Author
Peggy Aycinena is managing editor of Visual Studio Magazine.