You know the story:  you have to make a substantial change to some of your code.  The sensible, safe, ''boring'' tactic would be to add the new code alongside the old, and refactor to boil down the differences to a single point of contact between the new stuff and the rest of the codebase.  That sounds like a lot of work, and it will probably take quite a long time.  Why not just check out all the code that needs to change, make all the changes and whack it all back once you're finished?  That sounds much quicker.  OK so the new code won't work with the old database, but you're releasing the new schema soon anyway, so why not just deploy the code and the DB simultaneously?  Easy!  After all, it would be redundant to have code capabable of talking to '''both''' versions of the database wouldn't it?

This type of thing seems to happen often enough that the only conclusion I can draw is that developers, deep down, enjoy pain.  Or maybe we like stretching our talents by ignoring the path of least resistance.

This tendency can obviously act against the principles of ExtremeProgramming, and can make it a struggle to stay on the path, especially in the early stages of adoption.  This is when having a good coach can make the difference between successful adoption and egg-faced failure.

--DarrenHobbs

----
[Category: ExtremeProgrammingImplementationIssues]