Conclusion

<< XP's Values

A common attitude amongst XPers is that if you're not using XP, then you're one of the "old guard": you're crusty, old-fashioned, not up with the times. Horsefeathers.

Software development is a constantly evolving discipline. Check any project management/software engineering website and you will see new ideas; new wisdom.

Similarly, XP is new and evolving. It's young, naive and popular amongst programmers. The trouble is, in many ways it's a leap in the wrong direction.

The XP belief is that it's okay to throw away the rulebook and redefine what is possible. That's nice, as long as your new ideas are sound. Unfortunately, the thinking behind XP is dodgy in the extreme.

Alternatives to XP

Not using XP does not have to mean turning your back on software agility. It is possible to develop software with evolving requirements, with customer involvement and high visibility of progress, in a much more rigorous fashion than XP prescribes. Similarly, spending a little extra time getting the customer requirements right early on doesn't make the project non-agile.

Despite its flaws, XP's practices can also be tweaked to make the overall process more robust. Don't get too caught up in blind adherence to one methodology. Try not to end up chasing your own tail in order to be agile. Software agility is useful, but it's simply a means to an end.

Apply whatever practices that work for your project. Read the Steve McConnell books cover to cover (he's got it right, including the Evolutionary Delivery stuff). Use what's right for you.

Feature Driven Development (FDD) vs XP
A development process that fulfils the agile goals, yet still keeps a high emphasis on up-front design and documentation. Masterfully done.

FDD scales, enabling teams larger than 10 programmers; FDD develops an overall domain object model:

"The enormous difference between XP and FDD is FDD's additional development of an overall domain object model. As developers learn of requirements they start forming mental images of the system, making assumptions and estimating on that basis. Developing an overall domain object model forces those assumptions out into the open, misunderstandings are resolved and a more complete, common understanding is formed"

Rational Unified Process (RUP) vs XP
I recently published an article criticising RUP for its tendency to prey expensively on poor, confused consultants who don't know any better (and really should). However, RUP still provides many advantages over XP (emphasis on requirements and design modeling, for example).

RUP does have a big disadvantage, which is that there is so much of it. Up until recently it was difficult and time-consuming to "strip out" the parts of RUP that weren't needed for your particular project - although this has improved a lot in recent versions. The main advantage of RUP is that none of it is really new: it is all based on best practices that have been tried and proven in the field, many times over. (This is as opposed to XP which is also nothing new, but is based on unstable practices that used together prevent each other from toppling over).

Kent Beck (the "prime extremo") suggested that XP is essentially a subset of RUP. Perhaps in the sense that a mouse is a subset of an elephant.

ICONIX Process
I have a vested interest in this one as I recently co-wrote a book on it. ICONIX Process can be applied to XP projects to reduce requirements and design churn. It's particularly effective for collaborative up-front modelling sessions. The emphasis in ICONIX is on how to get from requirements (use cases) to code reliably in as few steps as possible. Well worth a look:
http://www.iconixsw.com/ICONIXProcess.html

Extreme Programming Refactored
In this book (co-authored with Doug Rosenberg), we suggest some modifications to the XP practices (plus some additional practices) to achieve XP's agile goals in a more rigorous and less risk-laden way.

Why not leave a message on the Software Reality XP Forum?

<< Back to XP Central

<< Back to Lifecycle