>What is missing from the Eclipse Development Process?

>What is missing in the Eclipse Development Process?

It’s a question I’ve been asking a lot lately. The EDP covers the high level management techniques that a project should go through. It discusses items like Project Creation, Planning, Milestones, Release Candidates, Reviews, and Releases. What it doesn’t cover is the Technical development practices. While it mentions a bit about Continuous Integration, it really is not true continuous integration. It’s better than not building regularly, but it in my humble opinion does not go far enough.

I’m a big fan of the agile management discipline called Scrum. However, Scrum by itself with out some of the critical technical practices of XP will fail. I’ve seen it happen. I’ve participated on such projects. A streamed lined management process is not enough, you have to have good practices to go with it. As it stands here the EDP, probably intentionally, leaves the technical aspects out of the equation. It basically says, 1 week of planning, 1 week of stabilization, and the rest is a “Magic Black Box” where stuff is produced. EDP starts off well for a project in the beginning because there isn’t much technical debt, as the project grows and matures, the areas that EDP doesn’t address start to show.

Uncle Bob Martin has a great keynote that he gave at SDWest on the subject. He practiced this at a user group meeting which they recorded.

This is the type of keynote I’m looking for when I go to a technical conference for developers. The problem we are starting to see with the EDP are due to the lack of clearly stating what the minimum technical practices should be. What are some problems?:

  • Builds that stay RED for weeks on end.
  • Commenting out Tests because they “randomly” occur.
  • Code Freezes for stabilization.
  • Code that is checked into head that is broken.
  • Trying to decipher what code is doing.
  • Hesitation to change code to improve it.
  • Code fixes that go in with out unit tests to test regressions.

The above are just some of what I’ve witnessed. Others will have their own lists.

Part of the problem is that the EDP is setup for Feature development only. This is a fact backed up by the fact that Features are addressed before the backlog of bugs are fixed. In fact the EDP process specifically outlines 6 milestones for features, and 1 milestone for performance and bug fixes.

Let’s look at that again…6 milestones for features. 1 Milestone for bug fixes. Plus, the so called release candidates. If done right, you should be able to release at any of the milestone stages.

Due to the Feature driven emphasis, what happens, features are worked on, and bugs go unaddressed until the end. The technical debt (bugs) that you incur from new features pile up. It slows down your development, you can’t change the code, you run into expanded time frames, and the code starts to become more difficult to maintain. Refactoring, Unit Testing, and Functional Tests, as well as bug fixes should happen every milestone, not left to the milestone before release candidates.

The EDP as a management practice is decent…but the EDP alone will not guarantee a successful release train or project. In fact the EDP alone, just starts to be the problem. The technical practices need to be clearly stated, and consistently followed by the community as a whole. What may work internally commercially may not necessarily work externally in the open source world.

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

4 Responses to >What is missing from the Eclipse Development Process?

  1. Wayne says:

    >Hi David. The Eclipse Development Process purposefully avoids prescribing the technical development process with too much detail. We instead prefer to leave it to the individual projects to establish those lower-level practices and principles.

  2. David Carver says:

    >@Wayne: Yeah I understand that is what it currently does, however, that practice is causing problems. Maybe it just needs to recommend some of the core principles that have become best practices in the open source community.The issue that I see happening is that commercial committers are just repeating what they do in their day to day development. Unfortunately, this can lead to broken builds, conflicts with working globably, and being able to release good quality code that benefits the user community as a whole.Take a look at most large scale eclipse projects, and there are very few that have builds that do not have days where they are broken. Usually it’s a mad scramble to fix the build a couple of days before Milestone data arrives. It’s an issue that needs to be addressed by at least recommending and maybe providing where possible education on different approaches. Just a thought.

  3. Le ScaL says:

    >You say “that practice is causing problems.”. Could you please elaborate to whom this cause problems? To whom addressing those problems would bring value?You have to remember that it is already hard to force the must do’s and the should do’s for a release train, and people have been complaining that we are taking the fun away from them by having those, so I’m not sure ppl would love being told how to produce software. After all evolution happens from diversity.

  4. David Carver says:

    >@Le ScaL:The best thing I can say is that from experience the should do's and must do's are fairly small. Adding some basic common technical practices to the coding actually helps makes amount of time you are spending on the Release train less, while allowing you to get more coding done.To understand your particular situation I would have to know what Development issues are the problem. What development issues are causing you delays in your project. I agree that in some cases the release train to dos and must dos are a little much, however, I don't think they are entirely to blame. The lack of running unit tests after every code check in, the lack of unit tests to go with bug fixes, the time frame devote to bug fixes, and also specifically how often a committer integrates their code with their fellow developers in the source code repository are bigger issues. Especially when you deal with a global team.If I check out code from head, I suspect that code to a> be clean, b> pass all of the unit tests, c> have unit tests to go with that code so I know that it is working. It helps to give that added confidence that the system is working as designed. The key though is getting the team to integrate their code several times a day and work in small pieces. If big massive merges are done, then the team suffers. If builds take 6 hours to complete before getting a unit test report back, then the team suffers. It causes Milestone builds to go out with failing tests. Or it causes you to have to work extra hours trying to get the build to pass before the Milestone is posted. All of this takes away time that you could be working on coding, fixing bugs, and in general enjoying coding again.How much you feel the pain of on the coding side will vary by project. Some feel it more than others. As coders we like to blame the Management process for the problems, however, sometimes it's our development habits and those of the fellow committers that maybe the actual cause.

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