CM and eXtreme Programing 

While having a few drinks at the pub, a Software Engineer announced that Xtreme Programing would soon make SCM obsolete. An interesting observation, no doubt enhanced by one too many at the beer repository.   However I have heard this before and I feel it would be appropriate to mention a few reasons why XP makes very little difference in the world of Configuration Management.
 
So What is Xtreme Programming ?

 
In a few words XP is heavily incremental software development process based on using up-front testing,  more regular small releases and continuos integration. Its methodology aims to promote simplicity, communication, feedback and ultimately reduce traditional red tape.
 
XP (according to inventor Kent Beck) is characterized by 12 practices:

                            Planning Game
                            Small Releases
                            Metaphor
                            Simple Design
                            Testing
                            Continuous Integration
                            Pair Programming
                            Collective Ownership
                            Refactoring
                            40-Hour Week  
                            On-Site Customer
                            Coding Standards
 
What Xtreme Programming is not

 
XP is not the concept that developers should have so much freedom that 30 years of established best practices are thrown out the window. I think this could be fairly termed XSP i.e. Xtremely Stupid Programming.

So does XP need CM ?
 
Unquestionably Yes! (and Kent Beck never said otherwise), SCM is as valuable in XP as any other Software Engineering model i.e. I doubt you could realistically see a serious software project working without the following fundamentals:

• Managed source repository (i.e. supporting artefact sharing, security, branching etc).

• Change Visibility/Version Control (XP systems needs role back, XP developers need history etc).

• Mature Deployment Mechanisms (XP wants streamlining, XP wants automation).

• Stable Integration environments (Yes XP still needs integration tests).

• Stable production environments (In XP the business still comes first ... not developer flexibility).

• Management/QA metrics (analysis and forecasting are useful whether team is using XP or Not).

So why the Myth ?

The myth of XP not needing SCM is because XP recommends frequent builds/integration. This is taken by some to mean that developers will do the builds (which is fine) and that an SCM manager will have no job to do. Unfortunately that simple theory is flawed, firstly because builds are just a small part of UCM and secondly because the projects still require a CM manager to ensure builds follow obvious best practices.

Final Comments

XP, like other software methodologies, has its own particular needs and challenges i.e. there is an obvious requirement to consider things like increased code sharing and the fluidity of integration. However in my experience these are merely project intricacies, I am yet to be convinced that any modern development process has moved beyond the needs (or abilities) of traditional CM.

Want to know more about XP: http://www.xprogramming.com.

Credits: Thanks to a drunken friend (who will remain nameless).

Copyright © 2002 SnuffyBear Company (Sydney Australia).