how (8 years of) eclipse changed my views on software development
Erich Gamma IBM distinguished engineer IBM rational zurich research lab
© 2008/2009 IBM Corporation
Outline
Open Source
2000
Fall Project Starts June
2001
Tech Preview
2002
November 1.0 June 2.0
2003
March 2.1
2004
June 3.0
2005 2006
June 3.1 June 3.2
2007 2008
June 3.3 June 3.4
Closed Development
Open Development
Built to Last Extensibility API
Community Transparency
Development Process Agility
Team Tools
Eclipse Lessons
how buildings last
• Stewart Brand: how buildings learn – what happens after they're built
• • • • stuff: furniture services: electrical, plumbing (7-15y) structure: foundation, load bearing walls (30-300y) site: geographical setting (forever)
• layers:
• evolve at different rates during the life of a building • shear against each other as they change at different rates • an adaptive building must allow slippage a building that lasts is adaptive and can change over time lasts for generations without total rebuilding
Site
© 2005 IBM Corporation
structure foundation
the eclipse plug-in architecture everything is a plug-in
simple and consistent
© 2005 IBM Corporation
eclipse plug-in architecture
plug-in == component
set of contributions smallest unit of Eclipse function details spelled out in plug-in manifest
plug-in
extension point – named entity for collecting contributions extension – a contribution
Example: a specific spam filter tool
plug-in
runtime – controls and manages contributions platform runtime
Extension Extension point
© 2005 IBM Corporation
services plumbing: APIs
Plug-in dependencies through APIs define APIs for stability
binary compatibility is highest priority
© 2005 IBM Corporation
APIs first
APIs don’t just happen; we need to design them specifications with precisely defined behavior
what you can assume (and what you cannot) it works ≠ API compliant documented classes ≠ API
must have at least one client involved, preferably more
© 2005 IBM Corporation
practical extensibility
extensible in ways that are known useful
needed by us, requested by others
we don't provide hypothetical generality - we want to be extensible in ways that matter
don't over generalize
© 2005 IBM Corporation
stuff, furniture - UI
eclipse extension architecture is contribution based
extensions contribute to the workbench the workbench manages and presents the contributions
enables UI evolution
3.0 new look
© 2005 IBM Corporation
Key Lessons
Modularity matters
Everything is a plug-in “no exceptions”
APIs are a huge commitment
we would rather provide less API than desired (and augment) than provide the wrong (or unnecessary) API and need to support it indefinitely the tyranny of stable APIs
API layers…
the challenge of product developers
which API level does our product require and support n–1, n-2
10
© 2008 IBM Corporation
Eclipse 3.4 API Tools
Support to define an API baseline
e.g. Eclipse 3.3 when working on 3.4
Check access restrictions
API javadoc tags: @noimplement, @noinstantiate, @noextend
Detect binary compatibility violations Detect version problems
@since
Problems are reported during builds
11
© 2008 IBM Corporation
stable API evolution patterns
compatibility layer I*2 extensions interfaces extension interface: IAdaptable restart in a new package
12
© 2008 IBM Corporation
extension interfaces: IAdaptable
IPersistable p= (IPersistable ) o.getAdapter(IPersistable.class); p.saveState(…);
supports adding interfaces to existing types Interface negotiation
13 © 2008 IBM Corporation
Outline
Open Source
2000
Fall Project Starts June
2001
Tech Preview
2002
November 1.0 June 2.0
2003
March 2.1
2004
June 3.0
2005 2006
June 3.1 June 3.2
2007 2008
June 3.3 June 3.4
Closed Development
Open Development
Built to Last Extensibility API
Community Transparency
Development Process Agility
Team Tools
14
© 2008 IBM Corporation
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
Shipping Matters…
our objective is to ship software anything that contributes to this goal is good anything that does not is bad team member recognition is based on the ability to ship quality software on time the culture: "If you ship, then you may speak." the question: "Did they ever ship anything?" the insult: "They never ship anything!"
Eclipse 1.0 Eclipse 2.0 Eclipse 2.0.1 Eclipse 2.0.2 Eclipse 2.0.3 Eclipse 2.1 Eclipse 2.1.1 Eclipse 2.1.2 Eclipse 2.1.3 Eclipse 3.0 Eclipse 3.0.1 Eclipse 3.0.2 Eclipse 3.0.3
Nov 2001 June 2002 Sept 2002 Nov 2002 Mar 2003 Mar 2003 June 2003 Oct 2003 Feb 2004 June 2004 Sept 2004 Mar 2005 Jul 2005
November 2001: “Open Source”
Reaction from the development team
You want us to do what? Why are we doing this again? Code in public? Answer all those dumb questions? Have technical discussions in public?
Key Lessons
Transparency helps existing development Better understanding of current status Responding to feedback takes time, but pays off Transparency Use same communication channels Developers inside as outside Not limited to Open Source projects “Open Commercial Development”
Community
Feedback and Support
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
Outline
Open Source
2000
Fall Project Starts June
2001
Tech Preview
2002
November 1.0 June 2.0
2003
March 2.1
2004
June 3.0
2005 2006
June 3.1 June 3.2
2007 2008
June 3.3 June 3.4
Closed Development
Open Development
Built to Last Extensibility API
Community Transparency
Development Process Agility
Team Tools
The Eclipse Way Practices
continuous testing sign off end game
reduce stress
continuous integration
drive with open eyes
validate
consume your own output
enable
transparency
community involvement
attract to latest
always have a client component centric
explore
live betas
validate
milestones first
feedback update
show progress learn
new & noteworthy
enable
API first
adaptive planning
retrospectives
dynamic teams
common agile practices common Open Source practices scaling-up practices
validate
Eclipse Lessons
Our Expanded Practices Today
continuous testing sign off end game
reduce stress
continuous integration
drive with open eyes
validate
consume your own output
enable
transparency
community involvement
attract to latest
always have a client component centric
explore
live betas
validate
milestones first
feedback update
show progress learn
new & noteworthy End of iteration demos/reviews
enable
API first
adaptive planning Product Backlog
retrospectives
Burndown dynamic teams Daily Standup Adoptions Expectations
Stories
validate
PMC Buddy Review Eclipse Lessons
What is behind the Eclipse Way
Practices underpinned with values
ship quality on time
Used, developed and improved over time
A mix of practices that worked for us Another mix of practices works for others
Practices are from all kinds of sources
XP, Scrum, Crystal Clear, RUP, … Patterns - Organizational Patterns of Agile Software Development – Coplien
It is not low ceremony
Approvals, verifications, reviews
It is agile: incremental, iterative, collaborative, transparent, customizable
And it scales up
Eclipse Lessons
In the Past…
Say goodbye to your loved ones
Look at calendar. Effort/ Pain Level Heads down Exhaustion All the time in the world
Time
Eclipse Lessons
Iterative – No hanging rope
fitness
In the past
t
3.1
no “hanging rope” ⇒ stress reduction
3.2
Eclipse Lessons
3.1
decompression warm-up retrospective initial release plan plan M1 6 weeks develop stabilize plan M2 develop stabilize plan … 6 weeks develop stabilize fix - spit & polish test fix
Eclipse Lessons
Iterative – Time-boxed
release 3.2 sign-off
fitness 6 weeks
sign-off endgame
sign-off
test
Continuous…
It is all about being continuous
Continuous iterative and adaptive planning Continuous design/refactoring Continuous integration/testing Continuous delivering/demos Continuous feedback Continuous learning
Many effective teams work like this
Eclipse Lessons
Key Lessons
Agility can scale up to globally distributed teams … but it would be nice to have better tool support
Eclipse Lessons
Outline
Open Source
2000
Fall Project Starts June
2001
Tech Preview
2002
November 1.0 June 2.0
2003
March 2.1
2004
June 3.0
2005 2006
June 3.1 June 3.2
2007 2008
June 3.3 June 3.4
Closed Development
Open Development
Built to Last Extensibility API
Community Transparency
Development Process Agility
Team Tools
Eclipse Lessons
Reflections from an Eclipse PMC Lead
Many Eclipse observers do not realize the amount of work/stress/human factor involved in shipping on time every time. It reminds me of the duck quietly advancing on the pond, but no one realizes that he is paddling like crazy underwater. Philippe Mulet – former Eclipse PMC Lead
Eclipse Lessons
But… there are Pain Points…
joining a team get my environment configured to be productive what is happening in my team collecting progress status Collaboration following the team’s process ad hoc collaboration/sharing of changes starting an ad hoc team is the fix in the build? Development what will be in the next build? tracking a broken build Avoid breaking a build/personal build why is this change in the build? reconstructing a context for a bug/build failure creating, tracking iteration plans interrupting development due to a high priority bug fix working on multiple releases concurrently tracking the code review of a fix referencing team artifacts in discussions how healthy is a component? collecting project data/metrics?
Boring and painful Project Management
Eclipse Lessons
Why are we doing Jazz?
Late 90’s: Focus on Point Tools Late 90’s: Focus on Point Tools
Who can build the best Java IDE, the best C IDE, the best Web Tool,…
When we built Eclipse: Focus on One Developer When we built Eclipse: Focus on One Developer
Seamless integration across a set of tools to improve the productivity of one developer
Today, we must focus on the Team and its Collaboration Today, we must focus on the Team and its Collaboration
Geographically Distributed Accelerated Delivery Demands Agility with Predictability Innovation and Repeatability Increased Need for Transparency Seamless integration across Seamless integration across all the Phases of the Software Lifecycle all the Phases of the Software Lifecycle to improve to improve the Productivity of the Entire Team. the Productivity of the Entire Team.
Eclipse Lessons
Jazz and Team Concert
Eclipse Lessons
Team Concert
Collaboration in Context Team First Process Transparency
Eclipse Lessons
Collaboration in Context
Eclipse Lessons
Collaboration with Context
Eclipse Lessons
Collaboration: Builds
Scoped builds
Personal builds Continuous team builds Scheduled integration builds
Collaborate in context on build failures
Eclipse Lessons
Rules/Process
All collaborations have underlying context specific rules Each project follows a process Team’s own their process
Eclipse Lessons
Process
Process manifested through:
artifact types and their states role-specific preconditions and actions on operations manipulating artifacts role-specific and permissions
Scrum
Eclipse Way
OpenUP
Eclipse Lessons
Transparency/Visibility: Dashboards
At a glance view on team artifacts Three dashboard types:
project team individual user
Viewlets
Eclipse Lessons
A Personal Dashboard
Eclipse Lessons
A Team Dashboard
Eclipse Lessons
Team of Teams Dashboard
Eclipse Lessons
Team of Teams Dashboard
Eclipse Lessons
Jazz Project Self-Hosting since Oct 2006
Toronto
Ottawa
Jazz Development Server
•Source Control •Reporting •Community Site
Bangalore
Beaverton
•VS Client
Lexington
•Build •Process
Zurich
Raleigh
•Source Control •Requirements •Interop •Repository •Web UI •Work Items •Agile Planning •Code Coverage
Eclipse Lessons
Summary: Our Journey
Eclipse Way
Try it yourself on www.jazz.net
Eclipse Lessons