Erich Gamma and John Wiegand started Tuesday afternoon's activities with a plenary session called "Stories along the Eclipse Way". This talk is a standard fixture in every EclipseCon.
Erich started with some EclipseCon metrics. A funny one was the elapsed time before talking with each other after the talk. Due to a battery snafu, John wouldn't talk to Erich for 50 minutes after the 2004 talk.
More serious metrics comparing 3.1 with what happened in 3.0 were given. For example, 3.1 had 31k JUnit tests instead of 21k JUnit tests. Lines of code has gone over 2 million. On comments on a single bug, a new record has been reached with 202 comments on a Linux performance issue. 41,555 bugs/enhancements fixed since day 1 (almost a bug fix per day per developer).
The priorities for Eclipse in 2005 were transparency, predictability, and feedback. These are still important but for 2006 the priority is going to be project health.
Project health is stronger than saying "quality". It's the state of a project over time, not just at a point in time. Staying healthy is a team responsibility. No single individual can make a project healthy by himself or herself. It's a shared thing; the team as a whole has to do stuff to keep the project healthy. And very importantly, once you're healthy, it allows the team to react to stress such as unanticipated changes, new directions, and so forth come in. A healthy project is active, while an unhealthy one is abandoned.
Health also implies accountability. You're accountable for your own health, but accountability is not the same as blaming: here's the situation, here's the choices, and here's the reason we did what we did. When someone takes on a feature from the plan, they take accountability for it and thus have to explain why it didn't happen. The teams doing the work have to be responsible for their own schedules. Project leads provide the context/themes, and component teams decide what they can commit to.
For example consider the performance effort. A JUnit performance testing infrastructure was put in place but nobody looked at the results. Nobody felt accountable. The fix was that in the weekly planning calls, everyone had to walk through the results, component by component. This made the components feel accountable and performance improved. In 3.2 we're in the same mode.
One health indicator is how quickly the community adopts milestones. This means the community can give very up to date information, plus it means the community feels it's stable enough to use. A healthy milestone is consumable. It has to have tested features, include a demo or new and noteworthy page. You should also notice a bug peak at the end of a milestone as lots of bugs are fixed.
It's critical that when you're defining a milestone, you shouldn't put down the "best case"; it has to be realistic. In addition, the rhythm of the release is critical. Comparing 3.1 and 3.2, you'll see only a 1 day difference between them. One change for 3.2: they've eliminated one milestone at the end to allow more time for the Callisto "end-game".
The "finish pattern" is a regular part of the milestones. It goes like this: warm-up Monday, validate Tuesday, test Wednesday, fix on Thursday, go/no-go on Friday, and planning and retargeting on Friday. By retargeting we mean moving features into the next milestone if they didn't get to them.
On testing and continuous building, the health of a weekly build is critical (the developers use it themselves). It's ok to break a daily build. Repeated breakage hurts, especially for the same reason because this indicates a lack of accountability. So we have a "micro-process" in place with recovery builds.
What does healthy collaboration look like? Good collaboration doesn't guarantee a project's success but poor collaboration almost always guarantees a project's failure. Each team is different but all the teams have to agree on some basic process elements (milestones, bug tracking, continuous integration). All teams (within Platform at least) share the same milestones. There are clear boundaries plus some friction to improve (polishing vs. grinding). Not all interactions are good, for example if you don't have good boundaries in place that can cause a problem.
Component leads act as communication hubs, but links between committers are important as well. The component lead should not be the bottleneck ("scale-free network"). Developers directly collaborate to find a solution for a particular problem.
UI health is a challenge. How can all the contributions from different teams and countries be brought together as an integrated whole. It's like cat herding, with developers as the cats. For example you have 256 pages of preferences in 34 categories. We don't have all the answers but have some suggestions.
What can you do to improve UI health? First, stay current. Know the Eclipse UI guidelines, know the basics, track JDT, and Platform UI. Don't harden UIs prematurely because they have to evolve and improve. Freeze them once they're good. Codify UI ideas in frameworks, like the Forms UI that came up from PDE. Leverage existing and proven frameworks. Push the platform to step up to some challenges, for example the search box in preferences.
More on UI health: slickness matters. Consider what is possible, and make it real. Finally, you can achieve a lot of stuff in the "spit and polish" time during the last 2-3 weeks. Ask the team what are some low-hanging fruits that would make it really better. A dynamic team tracks progress.
How do you ramp up to good health? Keeping a project healthy is a challenge but starting a new project is even harder. For example, what if you're not co-located? One solution is to have a kick-off session. Bring in the component leads and do a first cut of a plan (e.g., with sticky notes). The correlation between reality and what you plan may be low but it tells you what you need to do in the early stages.
Have your infrastructure in place early (SCM, collaboration, build, etc.). Realize your early milestones help you calibrate and establish expectations for later milestones. Build what you're shipping right off the bat, and do early coverage of as many parts as possible. Some early work will be discarded, and some deliverables will take longer. But keep the rhythm by breaking deliverables up into milestone-sized chunks.
Ramping up takes time. It took years to get the Platform into shape. Projects are not born fully formed. John reminded us that this is hard work. Eclipse started in 1999, had a tech preview in 2000, first release in 2001 but it was so-so. The 2002 2.0 release was OK, and the 2003 2.1 and 2004 3.0 release were even better. Trying to over-achieve can result in under-achievement.
Project health can deteriorate. There are "forces for badness" that are out there. Some examples are: code bloat (rewrite it), software rot (dormant and active), and bug pileups. Active rot happens when a new team member comes in and doesn't fully understand how things work so they add stuff on the side.
"Software isn't written but rewritten"
- Ralph Johnson.
There are many rewriting examples in Eclipse, but it's not a matter of throwing something away, rather making it better.
The primary focus for making "The Eclipse Way" better has been improving the existing tools (individual productivity). For example, developers noticed that plug-in development was a challenge, so over time they've made ongoing improvements for finding API violations, etc.. It's important to both build your own tools and consume them. Then upgrade from individual productivity to team productivity. Empower the team, and tool the process. Make transparent what's going on in a team: how do you integrate things? how healthy is the project?
Want to find out more? On the IBM side they're looking at building tools to make it happen. There's a BOF tonight on "Jazz" where some of John and Erich's work in this area will be demonstrated.
Take-away quote: "The Eclipse Way is for everyone. Learn it, try it, absorb it, and teach it to others."