Thesis 1: In several of its activities, XP strives for frequent, fine-grained adjustments. 

Thesis 2: Such frequent adjustments require equally frequent, fine-grained feedback.

Thesis 3: Feedback can be no more frequent or fine-grained than the units the activity itself is split up into.

Thesis 4: XP strives to make several of its activities as frequent and fine-grained as possible, up to the point where they approach being "continuous":

	* Constant Refactoring is the most continuous way to do design.
	* PairProgramming is the most continuous way to do code reviews.
	* PairProgramming is the most continuous way to teach and spread knowledge.
	* ContinuousIntegration is the most continuous way to do integration.
	* Doing only one card at a time and applying YAGNI is the most continuous way to add functionality.
	* Writing tests for every bit of functionality added and running them after every change is the most continuous way to do testing.
	* ...

--  FalkBruegmann, AnonymousDonor

------

Having established a tradition of vivid language, xp zelots use the adjective ''continuous'' when they mean much more frequently than normal. Continuous has a more precise meaning in math and physics, though it has fallen out of favor in the latter. Setting math, physics and even technology aside for a moment, let's think about just how continuous programming might be.

Imagine an IDE that launched the unit tests after every keystroke. What if they ran to completion before the next keystroke? Would you keep an eye on the GreenBar down in the status line? 

Imagine what it would be like if you got to green bar after every half dozen keystrokes. Suppose that your IDE integrated every time you did, and brought back the current codebase too. Would that be too much? Could you keep track of what is going on? 

Imagine that your IDE offered visual clues as to what was going on around you. Let's say that the feel of the system were like that of any modern network game. Would programming puzzles give way faster with simultainous cooperation (or competition) of other teams?

Imagine that you talk to your IDE instead of typing. Does that help? Imagine that you have a theorm prover and a planner working along with you and your partner. What would the conversation be like then? Imagine that simulations spawn visualizations so that the consequences of your every thought are plainly in front of you. Would you still struggle to maintain flow? Would it be hectic or relaxing? 

I had a friend who played basketball at lunch. I asked him what it was like when it was the best that it could be? He said the best parts were the instants where a play was developing and he knew where everyone was and what they were doing. That was the best it could be. Could we ever be anywhere close? -- WardCunningham

------
I've been itching to do something with clustered machines for a while.  What if all the unit tests for a system were run in a tuple space like JavaSpaces.  A system like that could help a team integrate all the more continuously.  I suppose that the issue would be whether network costs would outstrip computational costs.  This morning I looked around and noticed that there is a project called Joshua (described on http://www.junit.org) that is aiming to do this sort of thing.  What if it were carried further?  What if system builds were distributed with tuples? -- MichaelFeathers