ND8 DEVELOPMENT
Best Practice Software Development
© ND8
Thursday, July 23, 2009
The Rational Unified Process has, over the last few years, become the de-facto standard iterative and incremental development framework for OO and component based development. Agile is the new kid on the block offering a lightweight alternative to what has become viewed as a heavy weight process. Can RUP and Agile co-exist, or even complement each other, as development approaches?
RUP, and UML, were the product of three of the leading lights of OO development, Jacobson, Booch and Rumbaugh, when they consolidated their behavioural and data driven development approaches into a unified process and unified modelling language. In truth, these guys were reacting to an industry that was already taking the best of their individual methods and combining them to form complete, pragmatic processes (remember Select Perspective), based on Use Cases, interaction diagrams and class modelling.
RUP in particular offered a new paradigm in software development, its phases of Inception, Elaboration, Construction and Transition, offering more structure that the RAD processes of the time, but a radically different approach to standard waterfall.
Over the years I’ve watched RUP develop and in truth have not been impressed. It seems to me that the process has become bloated and gained a life of its own, whilst most RUP implementations continue to follow the same basic, lightweight, application of the techniques. Now Agile has come along and given it a well deserved kick up the backside.
However, before we consign RUP to history we should be wary of throwing the baby out with the bathwater. What made RUP such a good approach in the first place were those four phases and the objectives they promoted. Carrying out just enough work to size (and cost) the development, by understanding just enough about its scope and complexity - Inception – provides decision makers with crucial information early in the project life-cycle. Identifying and dealing with areas of high risk, and establishing the essential structure of the solution – Elaboration – remains as important as ever, especially on large, complex, multi-team projects. Having a dedicated phase aimed at putting the software live – Transition – emphasises the need
to be thinking (and costing) for these activities, well before that usual on development projects.
To my mind, what’s at issue is not these objectives but how these objectives are met. Crudely put an agilist would promote the view that understanding is best developed through evolving, extending and refactoring the code base, via short iterative development cycles and feedback loops. A RUP protagonist would broadly favour the development of models and specifications before the coding effort begins.
Five years ago I’d have been on the side of RUP, arguing that coding was simply too complex a task in its own right, and therefore big picture analysis and design considerations needed to be made up front. However even back then I would have argued for the lightest weight implementation of the process, in the knowledge that applying the 80/20 rule is key to driving software development forward.
However since then a new set of “Agile” techniques and tools (TDD, continuous integration, Junit, Clover, Findbugs, etc.) have been developed which together provide a framework that allows developers to design iteratively, refactoring code as the designs mature. These tools and techniques allow coding to start productively much earlier than has been possible in the past, and that in turn allows that all important early feedback from the user community.
So my belief is that for all but the most complex projects, the optimal approach is a one that favours RUP in terms of high-level phases, and Agile in how the objectives of the phases are met, with principles that look something like this:
Stick with the RUP phases in terms of objectives. They’re tried and trusted and when done well, add considerable value.
Always do the barest minimum to meet the objectives of a phase
Forget case tools and high ceremony models and specifications, for all but the most complex developments. Instead, when and where necessary informally whiteboard analysis and design to establish understanding and the essential structures. Always stop as soon as the value begins to diminish.
Move to code as quickly as possible, supported by tools that allow the code to be refactored as the design matures
Demo as early as possible and focus on a establishing a highly iterative feedback loop to gain understanding
Have at least one team member working ahead of the development iterations, focusing on user centric design and usability, and developing some initial “lo-fi” UI designs to seed the iteration
Fill in the detail as the system is coded, building a feature will involve some analysis, design, code and testing.
RUP & Agile - Friends or Foes?