Presumably, Erich Gamma and John Wiegand enjoy their day jobs as Distinguished Engineers at IBM Rational Software. If they ever feel a need for a change, though, they could do a lot worse than to take their act on the road. Their joint general session on the lessons of Eclipse, at the 2006 JavaOne conference in San Francisco, gave an authoritative and compelling look at a set of development practices that are demonstrably yielding excellent results over an extended life cycle involving widely distributed teams.

Presented on the morning of May 18, their session is available for viewing on the conference site, but I'd like to distill its key points here.

One of the Eclipse lessons learned is the value of continuous and transparent planning. The problem with most long-term development projects, said Gamma and Wiegand, is that their plans are only accurate at one point in time and that there's not enough bandwidth for feedback from users and developers on the trade-offs of value versus cost. Eclipse keeps its plans up to date and out in the open: Moreover, by classifying items as "committed," "proposed" or "deferred," Eclipse makes it clear to stakeholders that their concerns are recognized even if they can't be immediately addressed.

Another lesson to be learned from Eclipse is that the overall health and fitness of the code base should be maintained at a fairly high level, rather than being allowed to dip dangerously low for long periods of time between major milestones. Three danger signs, said Gamma and Wiegand, are "code bloat, software rot and bug pileup": They summarized their warning as "avoid broken glass," with a photo of a window in an abandoned building whose panes had all been shattered by vandals.

When a building looks run down and neglected, they said, no one respects it and the deterioration accelerates: A software project, they suggested, can suffer a similar fate if developers get the idea that it's no longer worth their best effort. From what I've seen, projects that drag out, defeature, and seem as if they're likely to wind up damaging the reputation of everyone who worked on them are at least as likely to trigger a flight response as they are a renewed determination to make them thrive.

Continuous demos, continuous consumption of the project's own output and continuous feedback are three other points that Gamma and Wiegand emphasized and that seem to me closely allied. For developer tools, that's almost a no-brainer: The phrase "tools to make tools" recurs in texts like Steven Levy's 1984 book "Hackers." Other organizations, though, should take advantage of approaches like service-oriented architecture to accelerate feedback by exposing work in progress to the people whose needs are supposedly being met.

Tell me how you're keeping your projects continuously healthy at peter_coffee@ziffdavis.com.

Click here for an archive of Peter Coffee's columns.

This article was originally published on eWEEK.com.