User Tools

Site Tools


blog:eclipse_way_core_values

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
blog:eclipse_way_core_values [2014/11/18 22:27]
djo [The Eclipse Modularity Story]
blog:eclipse_way_core_values [2018/02/01 11:37] (current)
djo [Isolate plug-ins from changes in dependencies of dependencies]
Line 1: Line 1:
-====== Combining Eclipse Way with XP and Scrum -- Core Values that Ship Success ​======+====== Combining Eclipse Way with XP and Scrum -- a Case Study ======
  
-In our previous installment,​ I gave Eclipse another shout out for their amazing perfect track record of shipping on time for 13 years. ​ I then described how I had the privilege of working with a team that, by intentionally adopting practices from Eclipse Way into our XP/Scrum process, achieved a similar perfect track record over a period of four years--with only a single emergency bug fix release.+//[Updated with light edits; February 1, 2018]// 
 + 
 +In our previous installment,​ I gave Eclipse another shout out for their amazing perfect track record of shipping on time for 13 years. ​ I then described how I had the privilege of working with a team that, by intentionally adopting practices from Eclipse Way into our XP/Scrum process, achieved a similar perfect track record over a period of four years, shipping every six weeks, ​with only a single emergency bug fix release.
  
 Here I'd like to describe the main practices from Eclipse Way that we incorporated into our XP and Scrum process that I believed played a crucial role in our success. ​ These practices are, in the order I will discuss them: Here I'd like to describe the main practices from Eclipse Way that we incorporated into our XP and Scrum process that I believed played a crucial role in our success. ​ These practices are, in the order I will discuss them:
Line 15: Line 17:
  
 Eclipse is built by multiple distributed teams numbering nearly 700 concurrent engineers (as-of the 2014 release). ​ In order to enable this many engineers to work together without constantly breaking each others'​ code, Eclipse designed a plug-in system into the architecture from the beginning. Eclipse is built by multiple distributed teams numbering nearly 700 concurrent engineers (as-of the 2014 release). ​ In order to enable this many engineers to work together without constantly breaking each others'​ code, Eclipse designed a plug-in system into the architecture from the beginning.
 +
 +In my experience, there are two key aspects to this plug-in system that help it to succeed as well as it has both technically and from a product-management perspective. ​ These are:
 +
 +  - **Internal vs. External API:​** ​ Eclipse separates code that is intended to be consumed by other projects from internal implementation detail. ​ Further, developers provide strong guarantees to customers that External API may be evolved, but not in a way that breaks their code.  Internal APIs, on the other hand, may break, change, or be completely rewritten as needed.
 +  - **Isolate plug-ins from changes in dependencies of dependencies:​** ​ Eclipse'​s plug-in engine sandboxes and isolates plug-ins from being able to view or change transitive dependencies of dependencies. ​ This minimizes "​version hell" caused by these transitive dependencies utilizing conflicting versions of the same library. ​ The purpose is again to enable interdependent projects to evolve independently.
 +
 +Here are a few more thoughts on each of these topics.
 +
 +==== Separate internal and external API ====
  
 A plug-in is a Java Jar that is divided into two kinds of APIs: A plug-in is a Java Jar that is divided into two kinds of APIs:
Line 24: Line 35:
 Steve Northover, the "​father of SWT", (the Eclipse GUI library) likes to say, "API is forever and @deprecated is a lie; somebody will always depend on your code". Steve Northover, the "​father of SWT", (the Eclipse GUI library) likes to say, "API is forever and @deprecated is a lie; somebody will always depend on your code".
  
-The article [[http://​www.eclipse.org/​articles/​article.php?​file=Article-API-Use/​index.html|How to use the Eclipse API]], while deprecated as-of this writing in my opinion still provides valuable perspective on API best practices. ​ In addition, Eclipse'​s wiki contains several articles on [[https://​wiki.eclipse.org/​Evolving_Java-based_APIs|Evolving Java-based APIs]] with detailed information for practicioners ​interested in building strong API guarantees into their products, even if they are not building on top of Eclipse or OSGi infrastructure.+The article [[http://​www.eclipse.org/​articles/​article.php?​file=Article-API-Use/​index.html|How to use the Eclipse API]], while deprecated as-of this writing in my opinion still provides valuable perspective on API best practices. ​ In addition, Eclipse'​s wiki contains several articles on [[https://​wiki.eclipse.org/​Evolving_Java-based_APIs|Evolving Java-based APIs]] with detailed information for practitioners ​interested in building strong API guarantees into their products, even if they are not building on top of Eclipse or OSGi infrastructure.
  
 API is a deep topic and worth much more than this brief introduction. ​ If there is demand, I can write more about that.  ​ API is a deep topic and worth much more than this brief introduction. ​ If there is demand, I can write more about that.  ​
  
-The second aspect ​of the Eclipse ​dependency story is Eclipse'​s OSGi container.  ​This is because, ​in addition to allowing plug-in jars to declare what packages are APIs, the Eclipse container allows plug-ins to declare their dependencies similar to the way Maven projects declare dependencies. ​ And the container enforces ​these dependencies ​at run-time.+==== Isolate plug-ins from changes in dependencies ​of dependencies ==== 
 + 
 +In Eclipse, plug-ins run inside ​Eclipse'​s OSGi container.  ​OSGi adds an additional benefit to Eclipse'​s plug-in and API story: 
 + 
 +In addition to allowing plug-in jars to declare what packages are APIs, the Eclipse container allows plug-ins to declare their dependencies similar to the way Maven projects declare dependencies.  ​ 
 + 
 +And the container enforces ​that a given plug-in jar only has access to the exact libraries/​versions that it declares as dependencies, and **not** any transitive dependencies of dependencies. 
 + 
 +Since plug-ins do not see transitive dependencies among each other, this minimizes conflicts caused by dependencies of dependencies depending on differing versions of the same library and enables plug-ins to evolve independently of each other by multiple teams around the world. 
 + 
 +While this approach doesn'​t solve every problem related to "jar version hell", it goes a long way toward keeping differing teams from breaking each others'​ code when they change their dependencies or dependencies'​ versions.
  
 We obtained substantial benefit by using Eclipse'​s OSGi container. ​ Non-Eclipse projects may wish to consider [[http://​karaf.apache.org/​|Apache Karaf]] as an alternative. We obtained substantial benefit by using Eclipse'​s OSGi container. ​ Non-Eclipse projects may wish to consider [[http://​karaf.apache.org/​|Apache Karaf]] as an alternative.
  
-However, while we realized substantial gains by using an OSGi container, I believe that disciplined adoption of Eclipse'​s API conventions can realize significant modularity gains, even when implemented outside of an OSGi container.+That said, while we realized substantial gains by using an OSGi container, I believe that disciplined adoption of Eclipse'​s API conventions can realize significant modularity gains, even when implemented outside of an OSGi container.
  
 Lastly, this blogger would encourage the Java community to evolve a solution that unifies the current dichotomy between Maven'​s dependency architecture and OSGi/​P2'​s. Lastly, this blogger would encourage the Java community to evolve a solution that unifies the current dichotomy between Maven'​s dependency architecture and OSGi/​P2'​s.
Line 52: Line 73:
 In Eclipse Way, user stories only need to be delivered every six weeks--on the release schedule--as opposed to at the end of each sprint. In Eclipse Way, user stories only need to be delivered every six weeks--on the release schedule--as opposed to at the end of each sprint.
  
-This encouraged us to group related user stories together as "​themes"​ to be delivered in a single milestone. ​ This also reduced end-of-sprint stress by eliminating the need to get the burn-down chart to absolute zero at the end of the sprint.+This encouraged us to group related user stories together as "​themes"​ to be delivered in a single milestone. ​ This improved our estimations by enabling us to subdivide user stories to a small enough granularity that they could easily be estimated. ​ And this reduced end-of-sprint stress by eliminating the need to get the burn-down chart to absolute zero at the end of the sprint. 
 + 
 +In addition, since the commitment we made to the customer was at the level of themes, (which are imprecise groupings of stories that deliver substantially on a particular set of features) we had flexibility about the exact amount of functionality that was delivered as a part of that theme in each release. ​ Consequently,​ we found that delivering on themes rather than specific user stories tended to be less stressful and easier to negotiate with the customer.  ​
  
-In additionsince the commitment we made to the customer was at the level of themes, ​which are imprecise groupings of stories that deliver substantially on particular set of featureswe had flexibility about the exact amount of functionality that was delivered as a part of that theme in each release.+In practiceit is often unnecessary ​to pin down the exact two-week period during ​which a specific user story will be delivered. ​ A six-week window is usually more than enough precision for most customersand many only require once-per-quarter precision 
  
-A result of this is that delivering on themes rather than specific user stories tends to be less stressful and easier to negotiate with the customer. ​ In practice, it is often unnecessary to pin down the exact two-week period during which a specific user story will be delivered. ​ A six-week window is usually more than enough precision for most customers, and many only require once-per-quarter precision. ​ In addition, adopting a six-week release schedule does not preclude introducing traceability into one's process, where customer requirements can be traced directly through themes, stories, and tasks to lines of code.+Lastly, adopting a six-week release schedule does not preclude introducing traceability into one's process, where customer requirements can be traced directly through themes, stories, and tasks to lines of code.
  
 ===== Ship Each Milestone ===== ===== Ship Each Milestone =====
blog/eclipse_way_core_values.1416367666.txt.gz · Last modified: 2014/11/18 22:27 by djo