>Is the Eclipse Development Process an Agile One?

>Ed‘s posting about rules and feeling blue resparked a thought I’ve had on and off over the last year. Is the Eclipse Development Process still an agile process? Bjorn replied to a comment I had posted to Ed’s original blog, unfortunately I never saw the reply, and owe him an answer. The short answer, Bjorn, is that I can’t put my finger on any one particular thing, it’s more of a general overall feeling, with some key points. Basically it comes down to how much control, and process is put in place and where. The more detailed analysis of this feeling is below.

Eclipse Development Process:

The Eclipse Development Process is the guiding principle for all Eclipse Foundation projects. The Development Process is not addressed until the last section. The prior sections are really dealing with how to create a new project, graduation of a project, and finally the release of the project. What I consider the development process to be includes:

  • Requirements
  • Planning
  • Development
  • Testing

While the above are pretty much the core of developing any type of software, how it is done, to what level of detail, and when it is done is a key to making a project agile. There are also some key concepts that make a process agile, as posted by Kelly Walters. In his article: 10 Key Principles of Agile Software Development. It’s a good general overview of what entails an agile process, and at first glance the Eclipse Development Process seems agile, but the process really isn’t about the development and how project should develop the plugins, it’s more of a development process for moving a project through eclipse’s various release and maturity stages.

The keys principles outlined are:

1. Active user involvement is imperative
2. The team must be empowered to make decisions
3. Requirements evolve but the timescale is fixed
4. Capture requirements at a high level; lightweight & visual
5. Develop small, incremental releases and iterate
6. Focus on frequent delivery of products
7. Complete each feature before moving on to the next
8. Apply the 80/20 rule
9. Testing is integrated throughout the project lifecycle – test early and often
10. A collaborative & cooperative approach between all stakeholders is essential

Overall the eclipse process follows these principles, but item 3 is starting to slowly deviate away from the principle. Let me explain this. The eclipse project plan is an important item. Adopters and the community should have an idea of what is coming down the line, however, the feeling I’m getting from this is that projects are starting to use it as a hard set set rule, that they can’t deviate from. If it isn’t on the plan, it won’t be worked on. You can’t have a hard set in stone plan and still be able to be agile, and react to changing conditions. What you thought would be a priority 6 months ago, might not be any longer. A plan needs to be as agile as the rest of the process, it must be able to be evolved and changed as it goes forward. Items that may have originally been in the plan, may need to be dropped. It’s a balancing act, between adopters wanting to know what is going to be in a particular release train, and the need for a committer and project to be able to adapt.

Item 10 is also at times being ignored out right. It doesn’t happen often, but I’ve seen it start to happen in various projects over the last year. An example would be a new feature is put into the project, without there being a corresponding bug, and some appropriate review period by the user community. Typically, this will come from an adopter that has committers on the project, and they want the feature in the product. All of a sudden the feature shows up, and if you go back to review the bugzilla backlog, there is no corresponding bug or feature request for it. The collaboration between a project’s stake holders is key to make sure that no one stake holder’s interest is taking precedence. What may be good for a particular stake holder may not necessarily be good for the project as a whole. It’s a difficult place for a committer to be put into, especially when a stake holder is paying them to work on a project.

Item 9 is one that is a pet peeve of mine. How many projects do not have adequate test coverage? How many projects have let a build go broken for days, weeks on an end? Has a milestone been declared even though the tests failed, just so that the milestone target date can be hit? Test have been commented out because they “randomly” fail. Testing is one of the corner stones of an agile process, it’s done often, it’s repeatable, and it’s automated. If a test fails, it’s given higher priority over anything else. However, many committers may not have had to do unit testing before. Primarily because their company that committed them to the project never had to do it. Understanding why testing needs to be done, and why it’s important to address failing tests, needs to be a higher priority for all eclipse projects. One thing I’ve learned, since really concentrating on tests, is that it really does make it much easier and quicker to change or migrate a design, and still make sure existing functionality is kept. With out a suite of unit tests for VEX, I would not have been able to make a transition to EMF for the VEX document model. Tests enable you to refactor code, with confidence, with out it, there is reluctance to do any major redesign or clean up of an existing framework.

As for the actual development of the software itself, make sure you are following the other principles. There are many methodologies, my personal favorite is a combination of XP and Scrum. XP gives a good set of rules and requirements to follow for the actual development of the code, and Scrum provides the necessary project management and planning. There are many others, but the key is only doing what is necessary and making sure you are involving all portions of the community.

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

5 Responses to >Is the Eclipse Development Process an Agile One?

  1. >Dave, This would make a great topic for the Architecture Council :-)FWIW, the “Eclipse Development Process” is primarily focused on the project lifecycle, not how individual projects choose to run their development. As a result, there is a lot of variability across the various projects at Eclipse on this front. However, some suggestions, best practices, etc. emanating from the AC could only be a good think IMHO.

  2. SteveL says:

    >This is interesting. Over in Apache-land, Apache Hadoop is working on a yahoo-driven process that, while strict, is more XP. Fixed timetable, and every features has Jira issue and proposed patches. Nothing goes in without an issue and review. Most interestingly, Hudson auto-rejects any feature which either breaks the build or doesn’t add new tests gets rejected. Reviewers may override that, but the default is no new tests: no commit

  3. gopack91 says:

    >I think this is an excellent post, and agree with much of it. The process is mostly in place, but we don’t hold people to following it strictly.

  4. >David,I agree with most of your observations here.I can suggest a few ways to fix some of the issues you mention:Every piece of code has to be backed by a test. I see this happening in the ruby/rails world, why not here, if a patch does not have tests for it, reject the patch, or if it is a must to include the patch, then someone(read the committer) writes a test for the code that is patched.Also I believe one reason that there are very few tests for most of the eclipse code is the fact that eclipse code is IMHO untestable, to say the least, and I’d really love it if someone proves me otherwise.

  5. David Carver says:

    >@Mike, good idea. I’ll see if it’s something we can address on the architecture council. Maybe we can come up with some recommended agile methodologies that can complement the Eclipse Development Process as a whole. As you said, the Development Process currently is for the project management/lifecycle, not for the actual development. Even though it dictates Milestones and Releases. I still think it should be up to the projects, but they need to document or at least specify which methodology and practices they are implementing. If their process isn’t agile, it doesn’t matter how much you make the EDP agile. You’ll run into issues.Again, I’ll see if I can help the AC address this.

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