Opinion: JavaOne presentation offers insights on consistent achievement.
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
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
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
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 firstname.lastname@example.org
Check out eWEEK.coms for the latest news, reviews and analysis in programming environments and developer tools.