Download presentation
Presentation is loading. Please wait.
1
© 2008 IBM Corporation Erich Gamma IBM distinguished engineer IBM rational zurich research lab how (8 years of) eclipse changed my views on software development
2
SECR 08 Outline Closed Development Open Development 2003 2000 2001 2002 JuneMarch June 2004 June 2005 2006 NovemberFall June 3.12.1 3.0 2.0 3.2 1.0Project Starts Tech Preview OpenSourceOpenSource 2007 June 3.3 Built to Last Extensibility API Community Transparency Development Process Agility Team Tools 2008 June 3.4
3
© 2005 IBM Corporation how buildings last Site 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
4
© 2005 IBM Corporation structure foundation the eclipse plug-in architecture everything is a plug-in simple and consistent
5
© 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 extension point – named entity for collecting contributions extension – a contribution Example: a specific spam filter tool runtime – controls and manages contributions plug-in platform plug-in Extension Extension point runtime
6
© 2005 IBM Corporation services plumbing: APIs Plug-in dependencies through APIs define APIs for stability binary compatibility is highest priority
7
© 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
8
© 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
9
© 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
10
© 2008 IBM Corporation 10 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
11
© 2008 IBM Corporation 11 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
12
© 2008 IBM Corporation 12 stable API evolution patterns compatibility layer I*2 extensions interfaces extension interface: IAdaptable restart in a new package
13
© 2008 IBM Corporation 13 extension interfaces: IAdaptable supports adding interfaces to existing types Interface negotiation IPersistable p= (IPersistable ) o.getAdapter(IPersistable.class); p.saveState(…); <factory class=“someAdapterFactory" adaptableType=“someType">
14
© 2008 IBM Corporation 14 Outline Closed Development Open Development 2003 2000 2001 2002 JuneMarch June 2004 June 2005 2006 NovemberFall June 3.12.1 3.0 2.0 3.2 1.0Project Starts Tech Preview OpenSourceOpenSource 2007 June 3.3 Built to Last Extensibility API Community Transparency Development Process Agility Team Tools 2008 June 3.4
15
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 The Swiss Bank approach to software development If it hasn't shipped it doesn’t exist Strong firewall between developers and customers
16
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!" 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 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 Eclipse 2.1.2 Oct 2003 Eclipse 2.1.3 Feb 2004 Eclipse 3.0 June 2004 Eclipse 3.0.1 Sept 2004 Eclipse 3.0.2 Mar 2005 Eclipse 3.0.3 Jul 2005 Eclipse 3.1 June 2005 Eclipse 3.1.1 Sept 2005 Eclipse 3.1.2 Feb 2006 Eclipse 3.2 June 2006 Eclipse 3.2.1 Sept 2006 Eclipse 3.2.2 Jan 2007 Eclipse 3.3 June 2007 Eclipse 3.3.1 Sept 2007 Eclipse 3.3.2 Feb 2008 Eclipse 3.4.0 June 2008 Eclipse 3.4.1 Sept 2008
17
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?
18
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 Not limited to Open Source projects “Open Commercial Development” Transparency helps existing development Better understanding of current status Responding to feedback takes time, but pays off Use same communication channels inside as outside Not limited to Open Source projects “Open Commercial Development” Community Transparency Feedback and Support Developers
19
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 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
20
Outline Closed Development Open Development 2003 2000 2001 2002 JuneMarch June 2004 June 2005 2006 NovemberFall June 3.12.1 3.0 2.0 3.2 1.0Project Starts Tech Preview OpenSourceOpenSource 2007 June 3.3 Built to Last Extensibility API Community Transparency Development Process Agility Team Tools 2008 June 3.4
21
SECR 08 The Eclipse Way Practices 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 dynamic teams show progress enable explore validate live betas feedback sign off common agile practices common Open Source practices scaling-up practices
22
SECR 08 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
23
SECR 08 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
24
SECR 08 Iterative – No hanging rope fitness no “hanging rope” stress reduction 3.1 t 3.2 In the past
25
SECR 08 Iterative – Time-boxed endgame release 3.2 fitness M1 plan develop stabilize 6 weeks warm-up retrospective initial release plan decompression 3.1 M2 plan develop stabilize … plan develop stabilize sign-off 6 weeks fix - spit & polish test fix test
26
SECR 08 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
27
SECR 08 Key Lessons Agility can scale up to globally distributed teams … but it would be nice to have better tool support
28
SECR 08 Outline Closed Development Open Development 2003 2000 2001 2002 JuneMarch June 2004 June 2005 2006 NovemberFall June 3.12.1 3.0 2.0 3.2 1.0Project Starts Tech Preview OpenSourceOpenSource 2007 June 3.3 Built to Last Extensibility API Community Transparency Development Process Agility Team Tools 2008 June 3.4
29
SECR 08 But… there are Pain Points… joining a team get my environment configured to be productive what is happening in my team collecting progress status following the team’s process ad hoc collaboration/sharing of changes starting an ad hoc team is the fix in the build? 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 Collaboration Development Project Management
30
SECR 08 Why are we doing Jazz? 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 Seamless integration across a set of tools to improve the productivity of one developer 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 all the Phases of the Software Lifecycle to improve the Productivity of the Entire Team. Seamless integration across all the Phases of the Software Lifecycle to improve the Productivity of the Entire Team.
31
SECR 08 Jazz and Team Concert
32
SECR 08 Team Concert Collaboration in Context Team First Process Transparency
33
SECR 08 Collaboration in Context
34
SECR 08 Collaboration with Context
35
SECR 08 Scoped builds Personal builds Continuous team builds Scheduled integration builds Collaborate in context on build failures Collaboration: Builds
36
SECR 08 Rules/Process All collaborations have underlying context specific rules Each project follows a process Team’s own their process
37
SECR 08 Process manifested through: artifact types and their states role-specific preconditions and actions on operations manipulating artifacts role-specific and permissions Eclipse Way Scrum OpenUP Process
38
SECR 08 Transparency/Visibility: Dashboards Viewlets At a glance view on team artifacts Three dashboard types: project team individual user
39
SECR 08 A Personal Dashboard
40
SECR 08 A Team Dashboard
41
SECR 08 Team of Teams Dashboard
42
SECR 08 Team of Teams Dashboard
43
SECR 08 Jazz Project Self-Hosting since Oct 2006 Beaverton Build Process Ottawa Source Control Reporting Community Site Zurich Work Items Agile Planning Code Coverage Bangalore VS Client Lexington Source Control Requirements Interop Raleigh Repository Web UI Toronto Jazz Development Server
44
SECR 08 Summary: Our Journey Eclipse Way
45
SECR 08 Workshop: 1400-1600 Scaling-up Agility to Globally Distributed Teams – How we build Jazz using Jazz
46
SECR 08 Try it yourself on www.jazz.net
Similar presentations
© 2025 SlidePlayer.com Inc.
All rights reserved.