an entry from

Piotr's R&D blog

Erich will be talking about agile, open source, distributed and on-time (and buzzword-compliant, apparently): inside the Eclipse development process. Unfortunately, his accent is difficult to understand over the microphone, and the font on his slides is barely readable [1]. Oh well.

In Eclipse development, the emphasis in on people over process, and on shipping software over other activities, producing a culture of "If you ship, then you may speak". They ship regularly, each milestone is a miniature development cycle so they get feedback early and often. Within a milestone, continuous integration is important (nightly, weekly and milestone builds), and of course they eat their own dog food daily. They also encourage and depend on community involvement, to avoid developing in a vacuum. This requires extra work and support on their part: for example, they weren't getting much feedback on milestone builds, because people didn't know what was new in each one, so they started publishing "new and noteworthy" lists and now get much better results.

Unsurprisingly, they also emphasize testing; the goal is to reduce the time between a bug appearing and being detected. They also have automated performance and resource (?) tests. In their release endgame, they alternate testing and fixing. They do not separate testing and fixing responsibilities: everybody does everything. After the release, they run a decompression cycle and retrospective. The timing is: 9 months of milestones, 1-2 months of endgame, 1 month of decompression.

The plan is prepared early, but remains alive until the day of the release. Risks are mitigated by putting high-risk stuff up front, and dropping things rather than pushing out the schedule. Everybody shares ownership of the code to ease resolving inter-component issues. Teams are put together dynamically to handle tough integration issues.

Eclipse is built to last, with an analogy to actual buildings. A building has multiple layers: the geographical location (permanent), structure (30-300 years), services (plumbing, electricity, 7-15 years) and stuff (furniture, replaceable easily). The various layers change at different rates, so the building's design must tolerate shear between the layers. This is painful but necessary if you don't want the building to become obsolete. In Eclipse, the structure is the plugin layer, the services plumbing are the APIs, the stuff is the UI. APIs matter, and are kept minimal and backwards compatible as much as possible. APIs are designed at the same time as the implementation and the client, to make sure they are practical, and serve to isolate components to maintain development velocity within each component (standard modularity argument).

Things don't always work out. Lower-layer ripples sometimes have a big effect on upper layers; as a result, they have a rule that a lower-layer change is not done until the ripple has (successfully) propagated all the way up. Dynamic teams are not always successful, and require lots of leadership and management support. Finally, they do drop features -- perhaps this could be seen as a gambit to avoid even worse things happening?

Footnotes

[1] Note to self: self, don't use fonts with thin lines, as they'll get washed out on the projector.

P.S. Why is it that today I see people coming in with breakfast goodies at 9:45am, but on Wednesday, when I was 5 minutes late, the breakfast had been taken away by 9am sharp? There is no justice in this world.