>In my entry yesterday, “EPF Composer, Scrum, and XP”, I made a statment that the Eclipse Development Process was showing some legacy affects having come from “IBM”. Also that it was based on the RUP (Rational Unified Process) or Open RUP process of doing software development. I still stand by this and I’ll do a bit of analysis and comparison between the Eclipse Development Process and RUP. So, this is a follow-up to Boris’s comments that the Eclipse Development Process does not have a IBM/RUP legacy.
Rational Unified Process:
The RUP process is a four phased cycle, each with iterations within those cycles. The big thing that RUP brings to a process is the iterative approach. Other than that it still separates most of the planning, development, and delivery of the product into separate phases.
The problem I have with RUP is that it still overloads the phases.. Everything isn’t done in every phase. This still leads to issues in being able to adapt to changes, lock down periods, etc. While it takes some values from Agile, it does not go far enough in my view.
The Eclipse Development Process:
Erich Gamma gave an updated presentation on the Eclipse Development Process at QCon 2008. The Eclipse Development shares a striking similarity to the Rational Unified Process.
You still have the same four phases of inception, elaboration, construction, and transition. Except Inception and Elaboration are combined into the “Warm-Up”, Construction are you milestone developments, and the Transition is the “End Game”.
So what is an alternative:
Personally I like a combination of Scrum for the Project management aspect and some concepts from Extreme Programming for development. The difference in Scrum compared to the current Eclipse Development Process and RUP is that it combines everything into the same iteration.
You are continuously gathering requirements, developing, testing, and transitioning during each iteration. The plan is continually updated. At the end of the iteration (called sprints), you have a shippable product. Shippable means all documentation, all tests, all deliverables are available at the end. There are no lock down periods, no code freezes, etc.
To acomplish this, one needs to enhance Scrum with some of the disciplines outlined by Extreme Programming.
Do I think this is a silver bullet. No. Do I think the current Eclipse Development Process is junk and should be scrapped. No. However, any development process that is starting to cause pain s for it’s end users, it’s committers, and community as a whole should be reviewed. I personally just do not think the current process meets the needs of the community as it stands now. So I still stand by my statement that the Eclipse Development Process is based on RUP. Whether by intention or not, it has that RUP feel to it.
Many of the issues can be addressed fairly simply by adopting good pragmatic programming practices. Unit Testing, Continuous Integration builds (from head), Integration Builds, Nightly Builds, Addressing Bugs over Features (i.e. paying off your Technical Debt). Many of these are small changes to way we currently work, and can be adapted slowly into the overall process.