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
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
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.
Peter Coffee is Director of Platform Research at salesforce.com, where he serves as a liaison with the developer community to define the opportunity and clarify developers' technical requirements on the company's evolving Apex Platform. Peter previously spent 18 years with eWEEK (formerly PC Week), the national news magazine of enterprise technology practice, where he reviewed software development tools and methods and wrote regular columns on emerging technologies and professional community issues.Before he began writing full-time in 1989, Peter spent eleven years in technical and management positions at Exxon and The Aerospace Corporation, including management of the latter company's first desktop computing planning team and applied research in applications of artificial intelligence techniques. He holds an engineering degree from MIT and an MBA from Pepperdine University, he has held teaching appointments in computer science, business analytics and information systems management at Pepperdine, UCLA, and Chapman College.