>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.