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 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 Id 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 theres 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 cant 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 its no longer worth their best effort. From what Ive seen, projects that drag out, defeature, and seem as if theyre 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 projects own output and continuous feedback are three other points that Gamma and Wiegand emphasized and that seem to me closely allied. For developer tools, thats almost a no-brainer: The phrase “tools to make tools” recurs in texts like Steven Levys 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 youre keeping your projects continuously healthy at peter_coffee@ziffdavis.com.
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.
