The Eclipse Way

The Eclipse Way
Daniel Megert
Eclipse Platform and JDT Lead
IBM Research - Zurich

2 © 2016 IBM Corporation
Why Did We Do Eclipse?
 Disrupt the growing dominance of Microsoft
 Solve our tool integration problems
 Create a community of plug-in providers

How we Started: Closed development
– The Swiss Bank
approach to software
development
• If it hasn't shipped
it doesn’t exist
– Strong firewall
between developers
and customers

History
 1998 - IBM conceives idea of universal tool integration platform
– Work starts on SWT
 1999 - IBM team starts work to build Eclipse Platform and Java IDE
– Based on 10 years experience with Smaltalk, VA/Java, VA/MicroEdition
 2001 - IBM donates Eclipse Platform and Java IDE to open source ($40M)
 2001 - IBM Eclipse team leads Eclipse evangelism and seeds community
– IBM funded receptions and Eclipse community events
– Keynotes, conference talks, articles by IBM technical leaders
– 55 Full time developers improving Eclipse and fully engaged with community
– First Eclipse-based products

November 2001: “Open Source”
Reaction from the development team
You want us
to do what?
Code in public?
Have technical
discussions in public?
Answer all those
dumb questions?
Why are we doing
this again?

Key Lessons
– Transparency helps existing development
• Better understanding of current status
• Responding to feedback takes time, but pays off
– Use same communication channels inside as
outside
CommunityCommunity
Transparency
Feedback
and Support
DevelopersDevelopers

Open Commercial Development
– Open Commercial Development is more than publishing
the source code
• Open, transparent process, from feature requests and
planning through delivery
– What can the community members do:
• Download milestones, try them, and provide feedback on
betas and incubators, including source code
• Access, Create, and update defects
• Access milestone and component iteration plans
• Access the development wiki
• Participate in discussions on the development community
newsgroups
– Example: www.jazz.net

The Eclipse Way
 The secret of the success of the Eclipse team
 An agile software development process
 Used, developed and improved over time by the Eclipse team

The Success of the Process
 The Eclipse team is shipping high quality
software on-time for many years now
–Continuous nightly builds on-time
–Weekly integration builds on-time
–Six week milestones on-time
–Yearly releases on-time
–Service releases on-time
 A healthy project
–Works on this high-level over years
–Continuously improving the process
Eclipse 1.0 Nov 2001
Eclipse 2.0 June 2002
Eclipse 2.0.1 Sept 2002
Eclipse 2.0.2 Nov 2002
Eclipse 2.0.3 Mar 2003
Eclipse 2.1 Mar 2003
Eclipse 2.1.1 June 2003

Getting Started
 Milestones first
–Small cycles (+/- six weeks)
 Early incremental planning
–Essential for many agile processes
 Continuous testing, Continuous integration
–Essential for many agile processes
 Endgame
–Stabilizing the product at the end of the release cycle
– No feature work allowed
 Decompression
–Essential to recover and improve the process over time

In the Past…
Time
Effort/
Pain
Level
Look at calendar
All the time in the world
Heads down
Say goodbye to your loved ones
Exhaustion

Iterative – No hanging rope
fitness
no “hanging rope”
⇒ stress reduction
3.1
t
3.2In the
past

Milestones First
 Break down release cycle into milestones
– We currently use 6 weeks
 Each milestone is a miniature
development cycle
– Plan, execute, test
– Teams refer to the release plan when
creating milestone plans
• Assign plan items to a milestone
• Milestone plans are public
 Result of a milestone
– Milestone builds: good enough to be
used by the community
 Milestones reduce stress!

Iterative – Time-boxed
endgame
Release 4.6
fitness
M1
plan
develop
stabilize
6 weeks
warm-up
retrospective
initialreleaseplan
decompression
4.5
M2
plan
develop
stabilize
…
plan
develop
stabilize
sign-offsign-off sign-off
6 weeks 6 weeks
fix
test
fix
test

Early Planning
 Establish big picture
– Team input
– Community input
 Sub-projects define their plans
 PMC collates initial draft project plan
– Tradeoff: requirements vs. available resources

The Plan is Alive
 The sub-project plans are updated as we go
– Progress on items
– New items
– Input from the community
 The project plan is updated quarterly
 Becomes final at the end of the release
 Before, and still practiced by many: static plans
– Accurate once, but no early feedback: non-existent until late
in the cycle.

Continuous Integration
 Fully automated build process
 Build quality verified by automated unit tests
 Staged builds
– Nightly builds
• Discover integration problems between components
– Weekly integration builds
• All automated unit tests must be successful
• Good enough for our own use
– Milestone builds
• Good enough for the community to use

Always Beta
 Each integration build is a release candidate; we expect it to work
 Results of the build process and the automated tests
– Indicate where we are
 As tool makers we use our own tools
– Developers use weekly integration builds
– Community uses release and milesone builds
 Continuously Consume Our Own Output
aka Eat your own dog food

Community Involvement
 Problem: no one knew what was in a milestone,
– So there was no incentive to move to milestone builds
– So we received minimal feedback
• More stale defect reports
– Quality suffered
 Solution: publish New and Noteworthy
– Advertise what we have been doing
 Requires transparency
– Community needs to know what is going on to participate
 Requires open participation
– We value the contributions of the community
 We are the community

Testing
 Innovate and refactor code with confidence
– Continuous incremental design
 Over 100'000 JUnit tests
 Tightly integrated into the build process
– Tests run after each build (nightly, integration, milestone)
– Milestone builds are only green when all tests pass
 Test / Report kinds
– Correctness tests: Assert correct behavior
– Performance tests: Allow to see performance regressions
• Based on a database of previous test run measurements
– Resource tests: no leaks and no resource consumption regressions
– API verification - breakage
– API verification - illegal use of internal/non API

Endgame
 Convergence process applied before release
– Sequence of test-fix passes (RCs)
• Community event
 With each pass the costs for fixing are increased
– Higher burden to release a fix for a problem
– Focus on higher priority problems and trivial fix/polish items
 Endgame endurance
– We are only effective for so long
– Distribute Quality/Polish effort throughout the release
– Shared responsibility and commitment
– We all sign off

Fixed Bugs

Decompression
 Recover from release
 Retrospective of the last cycle
– Achievements
– Failures
– Process
– Cross-team collaboration
 Explore new stuff
 Start to plan the next release and cycles

Our Practices – The Eclipse Way
milestones
first
API
first
end
game
retrospectives
always have
a client
continuous
integration
community
involvement
new &
noteworthy
adaptive
planning
continuous
testing
consume your
own output
component
centric
drive with
open eyes
validate
reduce stress
learn
enable
attract
to latest
transparency
validate
update
dynami
c
teams
show progress
enable
explore
validate
live
betas
feedback
sign
off
common agile practices
common Open Source practices
scaling-up practices

Conclusion
 The team makes the process work
 The team defines and evolves the process

The Eclipse Way

More Related Content

Viewers also liked (6)

Similar to The Eclipse Way (20)

More from Naresh Jain (20)

Recently uploaded (20)

The Eclipse Way