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:37]
djo [6-week Release Cadence]
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.  ​
  
-In Eclipse ​plug-ins ​run inside Eclipse'​s OSGi container. ​ OSGi adds an additional benefit to Eclipse'​s plug-in and API story:+==== Isolate ​plug-ins ​from changes ​in dependencies of dependencies ====
  
-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.+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 54: 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 features) we 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 customers, and 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.1416368241.txt.gz · Last modified: 2014/11/18 22:37 by djo