From Eclipse to Jazz

8/14/2019 From Eclipse to Jazz

1/46

2008/2009 IBM Corporation

Erich GammaIBM distinguished engineer

IBM rational zurich research lab

how (8 years of) eclipse changed my views on softwaredevelopment


2/46

Eclipse Lessons

Outline

Closed Development Open Development

2003200320002000 20012001 20022002

JuneMarch JuneJune

20042004

June

20052005 20062006

NovemberFall June

3.12.1 3.02.0 3.21.0ProjectStarts

TechPreview

OpenSource

OpenOpen

SourceSource

20072007

June

3.3

Built to LastExtensibility

API

CommunityTransparency

Development ProcessAgility

TeamTools

20082008

June

3.4


3/46

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/46 2005 IBM Corporation

structure foundation

the eclipse plug-in architecture

everything is a plug-in simple and consistent



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 collectingcontributions

extension a contribution

Example: a specific spam filter tool

runtime controls and manages contributions

plug-in

platform

plug-in

Extension

Extension point

runtime



services plumbing: APIs

Plug-in dependencies through APIs

define APIs for stability binary compatibility is highest priority



APIs first

APIs dont 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



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 thatmatter

don't over generalize


9/46

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



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 tosupport it indefinitely

the tyranny of stable APIs

API layers

the challenge of product developers

which API level does our product require and support

n1, n-2



Eclipse 3.4 API Tools

Support to define an API baseline

e.g. Eclipse 3.3 when working on3.4

Check access restrictions API javadoc tags:

@noimplement, @noinstantiate,

@noextend Detect binary compatibility

violations Detect version problems

@since

Problems are reported duringbuilds



stable API evolution patterns

compatibility layer

I*2 extensions interfaces

extension interface: IAdaptable

restart in a new package


13/46

13 2008 IBM Corporation

extension interfaces: IAdaptable

supports adding interfaces to existing types

Interface negotiation

IPersistable p= (IPersistable ) o.getAdapter(IPersistable.class);p.saveState();


14/46

14 2008 IBM Corporation

Outline


2003200320002000 20012001 20022002

JuneMarch JuneJune

20042004

June

20052005 20062006

NovemberFall June

3.12.1 3.02.0 3.21.0ProjectStarts

TechPreview

OpenSource

OpenOpen

SourceSource

20072007

June

3.3


API



TeamTools

20082008

June

3.4


15/46

How w e St ar t ed : Closeddeve lopmentHow w e St ar t ed : Closeddeve lopment

The Swiss Bank approach

to software development If it hasn't shipped

it doesnt exist

Strong firewall betweendevelopers and customers

The Swiss Bank approach

to software development If it hasn't shipped

it doesnt exist

Strong firewall betweendevelopers and customers


16/46

Shipping Mat t ersShipping Mat t ers

our ob jec t i ve is t o sh ip so ft w are

anything that contributes to this goal is good

anything that does not is bad

t eam m ember rec ogni t i on i s based on t he ab i l i t y t o

sh ip quality software

on time

t he cu l t u re : " If you ship, then you may speak."

t he quest ion : "Did they ever ship anything?"

t he insul t : "They never ship anything!"

our ob jec t i ve is t o sh ip so ft w are

anything that contributes to this goal is good

anything that does not is bad

t eam m ember rec ogn i t i on i s based on the ab i li t y t o

sh ip quality software

on time

t he cu l t u re : " If you ship, then you may speak."

t he quest ion: "Did they ever ship anything?"

t he insul t : "They never ship anything!"

J ul2005

Ecl ipse3.0.3

Mar

2005

Ecl ipse

3.0.2

Sept2004

Ecl ipse3.0.1

June2004

Ecl ipse3.0

Feb2004

Ecl ipse2.1.3

Oc t2003

Ecl ipse2.1.2

June2003

Ecl ipse2.1.1

Mar2003

Ecl ipse2.1

Mar2003

Ecl ipse2.0.3

Nov2002

Ecl ipse2.0.2

Sept2002

Ecl ipse2.0.1

June2002Ecl ipse2.0

Nov2001

Ecl ipse1.0


17/46

Novem ber 2001: Open Sourc eReaction from the development teamNovem ber 2001: Open Sourc eReaction from the development team

You want usto do what?

Code in public?

Have technicaldiscussions in public?

Answer all thosedumb questions?

Why are we doing thisagain?


18/46

K ey LessonsK ey Lessons

Transparency helps existingdevelopment

Better understanding of currentstatus

Responding to feedback takes time,but pays off

Use same communication channelsinside as outside

Not limited to Open Source projects Open Commercial Development

Transparency helps existingdevelopment

Better understanding of currentstatus

Responding to feedback takes time,but pays off

Use same communication channelsinside as outside

Not limited to Open Source projects

Open Commercial Development CommunityCommunityCommunityCommunity

Transparency

Feedbackand Support

DevelopersDevelopers


19/46

Open Com m erc ia l Developm entOpen Com m erc ia l Developm ent

Open Commercial Development is more than publishing thesource code

Open, transparent process, from feature requests andplanning through delivery

What can the community members do:

Download milestones, try them, and provide feedback onbetas 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 communitynewsgroups

Example: www.jazz.net

Open Commercial Development is more than publishing thesource code

Open, transparent process, from feature requests andplanning through delivery

What can the community members do:

Download milestones, try them, and provide feedback onbetas 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 communitynewsgroups

Example: www.jazz.net


20/46

Out l ineOut l ine


2003200320002000 20012001 20022002

JuneMarch JuneJune

20042004

June

20052005 20062006

NovemberFall June

3.12.1 3.02.0 3.21.0ProjectStarts

TechPreview

OpenSource

OpenOpen

SourceSource

20072007

June

3.3


API



TeamTools

20082008

June

3.4


21/46

Eclipse Lessons

The Eclipse Way Practices

milestones

first

APIfirst

endgame

retrospectives

always havea client

continuousintegration

communityinvolvement

new &noteworthy

adaptiveplanning

continuoustesting

consume yourown output

componentcentric

drive withopen eyes

validate

reduce stress

learn

enable

attract

to latest

transparency

validateupdate

dynamicteams

show progress

enable

explore

validate

livebetasfeedback

signoff

common agile practices

common Open Source practices

scaling-up practices


22/46

Eclipse Lessons

Our Expanded Practices Today

milestones

first

APIfirst

endgame

retrospectives

always havea client

continuousintegration

communityinvolvement

new &noteworthy

adaptiveplanning

continuoustesting

consume yourown output

componentcentric

drive withopen eyes

validate

reduce stress

learn

enable

attract

to latest

transparency

validateupdate

dynamicteams

show progress

enable

explore

validate

livebetasfeedback

signoff

End of iteration

demos/reviewsProduct Backlog

Burndown Stories

Daily Standup Adoptions

Expectations PMCBuddy Review


23/46

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


24/46

Eclipse Lessons

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


25/46

Eclipse Lessons

Iterative No hanging rope

fitness

no hanging rope

stress reduction3.1

t3.2In the

past


26/46

Eclipse Lessons

Iterative Time-boxed

endgame

release 3.2

fitness

M1

plan

develop

stabilize

6 weeks

warm-up

retrosp

ective

initialreleaseplan

decompression

3.1

M2

plan

develop

stabilize

plan

develop

stabilize

sign-offsign-off sign-off

6 weeks 6 weeks

fix

-spit&polish

tes

t

fix tes

t


27/46

Eclipse Lessons

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


28/46

Eclipse Lessons

Key Lessons

Agility can scale up to globally distributed teams

but it would be nice to have better tool support


29/46

Eclipse Lessons

Outline


2003200320002000 20012001 20022002

JuneMarch JuneJune

20042004

June

20052005 20062006

NovemberFall June

3.12.1 3.02.0 3.21.0ProjectStarts TechPreview

OpenSource

OpenOpen

SourceSource

20072007

June

3.3


API



TeamTools

20082008

June

3.4


30/46

Eclipse Lessons

Reflections from an Eclipse PMC Lead

Many Eclipse observers do not realize theamount of work/stress/human factor involved in

shipping on time every time.

It reminds me of the duck quietly advancing onthe pond, but no one realizes that he is paddlinglike crazy underwater.

Philippe Mulet former Eclipse PMC Lead


31/46

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

following the teams 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

ProjectManagement


32/46

Eclipse Lessons

Why are we doing Jazz?

Late 90s: Focus on Point ToolsLate 90s: Focus on Point ToolsWho can build the best Java IDE, the best C IDE, the best Web Tool,

When we built Eclipse: Focus on One DeveloperWhen we built Eclipse: Focus on One DeveloperSeamless integration across a set of tools to improve the productivity of one developer

Today, we must focus on the Team and its CollaborationToday, 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 Lifecycleto improvethe Productivity of the Entire Team.

Seamless integration acrossall the Phases of the Software Lifecycleto improvethe Productivity of the Entire Team.


33/46

Eclipse Lessons

Jazz and Team Concert


34/46


35/46

Eclipse Lessons

Collaboration in Context


36/46

Eclipse Lessons

Collaboration with Context


37/46

Eclipse Lessons

Scoped builds

Personal builds

Continuous team builds Scheduled integration builds

Collaborate in context on build failures

Collaboration: Builds


38/46

Eclipse Lessons

Rules/Process

All collaborations have underlyingcontext specific rules

Each project follows aprocess

Teams own their process


39/46

Eclipse Lessons

Process manifested through:

artifact types and their states

role-specific preconditionsand actions on operationsmanipulating artifacts

role-specific and permissions

Eclipse Way

Scrum

OpenUP

Process


40/46

Eclipse Lessons

Transparency/Visibility: Dashboards

Viewlets At a glance view on team artifacts

Three dashboard types:

project team

individual user


41/46

Eclipse Lessons

A Personal Dashboard


42/46

Eclipse Lessons

A Team Dashboard


43/46

Eclipse Lessons

Team of Teams Dashboard


44/46

Eclipse Lessons

Team of Teams Dashboard


45/46

Eclipse Lessons

Jazz Project Self-Hosting since Oct 2006

Beaverton

BuildProcess

Ottawa

Source Control

ReportingCommunity Site

Zurich

Work ItemsAgile Planning

Code Coverage

Bangalore

VS Client

Lexington

Source ControlRequirementsInterop

Raleigh

RepositoryWeb UI

Toronto

JazzDevelopment

Server


46/46

Eclipse Lessons

Summary: Our JourneyEclipse Way

Try it yourself on www.jazz.net

From Eclipse to Jazz

Documents

Transcript of From Eclipse to Jazz