I learned the Classic Development Cycle quite differently from most
people (it seems). My high school Comp Sci instructor (1979)
presented this basic software development flow and then immediately
used it to introduce concepts of iteration, recursion, and feedback
(on the model itself). I never felt that the Classic Development
Cycle approach was flawed, just most people's interpretation and
implementation of it (as a one-way monolithic process). To my mind,
modern methodologies like XP seem like natural extensions or
revisions of the classic model (as I learned it), not radical
departures.

One of the few real benefits of accumulating age, is that you begin to see that most if not all of the details of the 'new methodologies' that have a habit of springing up every 10 years or so are simply re-inventions, re-discoveries, re-interpretations or re-implementations of stuff that was known and formalised (in that laborious and dry-gulch way so beloved of the era) by the early pioneers in the field. The differences are mainly in the terminology used, the categoricality (sp? Is that a word?) of the dos and don'ts, and the formality and seperation between the stages.

In the good ol' bad ol' days, when (and by whom) the stages of the processes where performed was much more clearly defined and seperated. The main change (IMO) between the Waterfall method and XP, is that XP tends to encourage the iteration/recursion to happen much earlier and more frequently in the cycle than the older methods. It also encourages the coder to do this himself, and for himself.

In many ways, this mirrors changes in other industries, often termed "removal of demarkation". In the car industries of the '70s and '80s, production was done by production workers, maintainance by maintainance workers, testing by testers etc. etc. And so it was with software. Coders coded, testers tested, analysts analysed and designers designed.

In the early '90s (if memory serves), Volvo scrapped the production line system and moved to "production teams". Basically, they organised their (no longer demarkated) workers into teams. Each car was built by a single team. They did everything from production to testing to re-working. The effect was to make them jointly responsible for the overall output of their team. Each person was trained to do every function and they did what ever was required to get the job done. Not only did this vastly improve the quality of their output and reduce the amount of remedial work required, it also induced group reliance and responsibility and resulted in a higher sense of satisfaction, lower staff turnover and sickness.

I see XP in a similar light. It doesn't remove or add to the individual stages as laid out all those years ago in the CDC. It simply interleaves them, removes the levels of stratification that existed, and puts the onus upon the individual to produce and maintain a quality product rather than volume. The overall result should amount to the same thing, but in practice, the XP model tends to iterate or recurse earlier and less deeply, so the problem of "blowing the stack"1 tends not to occur.

1In perl terms, this is the dreaded "Deep recursion" followed by the worse "Out of memory". Many projects using the Waterfall model fell foul of 'blowing the stack', which meant that they ran out of support and then cash (which amounts to the same thing). It's not that they wouldn't have arrived at a working solution, its just that they got so far into the projects before they discovered the flaws, that they had a long way to backstep before they could move forward again. In the meantime, long development cycles meant that large sums of money went in without anything much coming out. Hence it became a regular practice (here in the UK I know for sure, but I think other places also) for entire software projects to be scrapped because the cash was cut off before the project could reach a stage of showing its worth.

The major change (and benefit) of the modern re-workings of the early development cycles is that the aim is to have something demonstrable as early as possible. Once you can demonstrate that progress is being made, it is much easier to carry good will (and the cash that comes with it) forward.

In development terms this translates to finding and remedying your bugs as soon as possible which results in smaller steps back individually and much less time moving backwards overall.

My tip encapsulates this idea, and was meant to encourage those starting out to not be afraid of moving backwards (a little). Every project, large or small, will always have to re-trace and re-group from time to time. Minimising the distance re-traced is the key.

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller
If I understand your problem, I can solve it! Of course, the same can be said for you.