>Tweaking the Eclipse Development Process

>Note 2009-04-15: It has been correctly pointed out that the six week milestone process is the actual “eclipse project” way of working within the Eclipse Development Process. This entry has been updated as appropriate.

A while ago, I compared the Eclipse Development Process (EDP) to that of the Rational Unified Processs. The EDP specifically addresses the steps that a eclipse project goes through to be released. It addresses a little bit on management, and touches only briefly on technical practices of actual development. I’ve been told that the Eclipse Foundation feels that how the code is developed is best left up to the individual projects. In general, I’m okay with that, as not every team works best the same way. However, for those teams that want to be more agile in their development, and incorporate some more technical practices what can be done?

The EDP can be interpreted in many different ways, which is good. The most popular way that eclipse projects have interpreted and worked within the EDP, is to follow the lead of the the top-level “eclipse project” which has it’s own OpenRUP like process (EPDP). This methodology is shown above from a management stand point. As can be seen by the picture above, it focuses on 6 week iterations. With one week for planning and one week for stabilization. In many cases during the plan, develop, stabilize you could write “Magic Black Box Here”. As we all know that the magic black box solves it all.

There are some challenges from an agile point of view with the EPDP. First, a team may not need a complete week for planning. They may not even need a stabilization week. However, some projects following the EPDP see it as being set in stone. That you have to do a week, and you have to have a stabilization week. Those not following the EPDP, planning can be shortened to a day, and a week for stabilization may not even be needed. While the EPDP does take some concepts from Agile processes it in my opinion does not go far enough to help document clearly the technical process that needs to go along with the management process. A picture does not clearly specify what all entails the EPDP, so I ecourage readers to review the information that is available on the Eclipse Projects wiki.

The EDP is a management process. It, however, is running into some of the same issues that SCRUM by itself experiences. SCRUM is an agile project management practice. Organizations that only implement an agile project management solution may not be gaining the full benefit of the solution. In fact, many companies or projects that just adopt SCRUM by itself, are not any more successful than the waterfall methodologies they replaced.

In my opinion, where these highly focused project management solutions fail, is not addressing the technical practices that are needed to make them a success. SCRUM is a great project management addition to other agile practices like XP, FDD, BDD, and TDD. With out some of the disciplines of the technical practices no project management practice is going to succeed.

Over the coming weeks, I’ll start to focus in on how I think the EDP can be enhanced with a bit of SCRUM for project management, and pieces of XP for project development. There are pain points that I’ll try to address including technical debt, builds that are never green (or rarely), and last minute cram sessions. Ideally an eclipse project should be able to declare a milestone or release quality build at any given day. Impossible? Unlikely? It can be done, it just takes a bit more discipline on our parts as committers to make it happen.

Update 2009-04-15:
One cautionary note is that there is a danger in assuming that the process followed by the Eclipse Platform is the right fit for all eclipse projects. So the release train and planning council should be flexible where possible to allow projects to participate without stating that they MUST follow a particular way of developing. The problem is that they specify Milestone Numbers based on the EPDP way of developing. Target dates of when items are to be completed should be given but not necessarily milestone dates, and then it’s up to the individual projects how best they see to accomplish this.

I challenge all projects after Galileo to review their process as a whole. If your project is constantly running into failed builds, rushing to get things done, or manually tweaking builds so they appear green just to make a milestone date, then your development process may need to be reviewed and tweaked to correct your pain points. Processes need to evolve…what worked in the past may not necessarily be the best solution for the present.

This entry was posted in agile, eclipse. Bookmark the permalink.

10 Responses to >Tweaking the Eclipse Development Process

  1. nickb says:

    >Just because a project claims its 6 week iteration will lose a week for planning and another for stabilization doesn’t mean in reality that’s what happens. But at least it’s stated up front that these steps are necessary, even if the time required to do them is shorter or longer than spec’d initially.

  2. David Carver says:

    >Well, is varies by project and what methodology they have choosen to use.However I see many projects use it as a strict rule…they’ll use the entire week whether they really need it not, because the EDP says to do it.

  3. Wayne says:

    >This is good stuff David. However, the EDP (as defined in the link you provide) doesn’t specifically state anything about a six week development process, or attempt to specify how much time should be spent planning, etc. The EDP is purposefully high-level to allow for flexibility at the individual project level.You are describing the development process followed by the Eclipse project. The Eclipse project is, as you know (but readers may not) just one of 11 top-level project at eclipse.org. It can be argued that the Eclipse project’s process has been very successful and is something that other projects (both at eclipse.org and elsewhere) should consider emulating. However, it is not something that we force all eclipse.org projects to do.It’s great that you’re taking leadership in this space; it’d be great if we (the Architecture Council) can provide a process template based on your work that other projects can use as a basis for their own localized development process. However, we need to make sure that we’re clear that the template is not the EDP: they are complementary.

  4. David Carver says:

    >@Wayne: Thanks for the very good point on the clarification. As most projects from my understanding and the process described by Erich Gamma in his presentations is focusing on the way the Eclipse Project is run. Which is the defacto standard that everything on the release train follows.There are some variations, I know that Mylyn does a much shorter cycle in development and releases more often.I’ll update the blog entry a bit to clarify the difference between the EDP which is a high level management of a release and the “Eclipse Projects” way of fitting into the EDP process.

  5. Wayne says:

    >I think it’s more accurate to say that “some” or perhaps “many” projects emulate the Eclipse project’s process (rather than “most”).Again, thanks for doing this. I think that it will make for a good template for consideration by projects.

  6. David Carver says:

    >@Wayne: thanks. I think I’m going to leave the wording as it stands, as from the view point of the Release train and the majority of the projects hosted at eclipse (I’d say 90%), follow the eclipse platform projects EPDP process.The issue I see is that projects feel that to be on the release train they have to follow the EPDP which isn’t necessarily true…but that is the impression that is conveyed, and even emphasized in the schedule that is produced. Hopefully through the this blog, the architecture council, and the eclipse wiki we can make it clear that there are other ways to work. Projects do not have to adopt the EPDP. It’s an option not a requirement.The last statement is what I think is being lost.

  7. >Hi, I wonder what’s wrong with RUP?What I have experienced: SCRUM is great but it is not enough. You need more from lean. And than more from RUP emerges: focus on architecture, explicit focus on risk. What’s wrong with EDP? What I read doesn’t provide an answer to “why/what”…

  8. David Carver says:

    >The “why” and “what” will come as I go through individual blog entries to flesh everything out.Scrum as you said isn’t enough…Just as RUP can be overly burdensome if you implement everything. OpenRUP is not enough, as it suffers from the same thing that Scrum suffers, no technical practices.For a complete process you have to outline both the Management and Technical Practices. One without out the other will eventually come back to haunt you.

  9. David Carver says:

    >@Roman: Yes OpenRup specifies technical practices…however EPDP (eclipse project devlopment process) is very loose when following those technical practices. For example OpenRUP specifies Continuous Integration but the way Continuous Integration is implemented in EPDP is not what is specified in OpenRUP, or in other practices. It doesn’t go far enough. Notice OpenRup suggests “The integrate-build-test cycle must be fast enough so that it can be completed quickly and the team notified of the results.” However a EPDP build can take 6 hours or longer to complete.Test Driven Development is suggested as well…however I know for a fact that the code is not written TDD style, otherwise it would be much easier to test than it currently is.Also OpenRUP suggests refactoring, and other items, that aren’t followed as well. EPDP took the management practices, and only a sliver of the technical practices.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s