Code Like Hell
06-26-2003, 09:24 AM
"Phlip" <phlipcpp@yahoo.com> wrote in message news:<3SLIa.2754$zX1.464@newssvr31.news.prodigy.com>... Code Like Hell wrote: Yes. Everything makes sense but the touch--what does that do, why is that important? What sorts of things can be communicated by touch? What about all the tension added by trying to communicate that way? What does touch contribute to the shared alpha in terms of developing it and feedback? Don't touch while pairing. (OH MY COD! A RIFT AMONG THE EXTREMOS! THEIR BUBBLE IS ABOUT TO BURST! HERE COMES THE SCHISM!!!)
SOYLENT XP IS PEOPLE!!!
Also, what about an attitude shift: Shared alpha would not get induced with this attitude: what if each member of the pair felt as if the other person might have information that they might need? Too much stress. "Alpha" rhythm is relaxed zoning. We want the human equivalent of the "Theta rhythm" found in animals. This occurs during our dream state, and when we are "in flow", which is when perniciously tracking one subject.
Theta rhythm was found in yogis and zen practitioners...it's the next
bigger wavelength than alpha, read that somewhere.
If your environment permits chronic improvements and positive reinforcement over one current task, without distractions from other tasks, you can enter "Flow". In this zone, every thought connects. When you emerge from Flow and take a break, you may be surprised to find hours have passed. The sun may have set, or dawned; you didn't notice.
Flow may require those conditions, for a relatively brief period, to
get started, but once the flame is going you can be interrupted and
even go home, with some passing unit tests...but you say this below.
XP supports easy starting and maintenance of the flame, where before
it was magic or you had to steal it.
In Flow, your short-term memory maintains an image of your current task. This memory behaves like a CPU's storage cache. Interruptions that replace the cache damage Flow. (Peaks in the intensity of your Flow will often inspire your loved ones, even at long distance, to select that exact moment to interrupt you.)
Wouldn't XP practices be geared for starting and building Flow, even
if you have a life? Ah I see you answer this below...
Our technical goals, TDD and PP, have distinct definitions, so we will know unambiguously when we have them. Our real goal is Flow, a subjective experience.
Flow is objectively measurable.
When you test, between hitting the test button and receiving a Green Bar, the tests should take care of every possible detail that enables your project's success; more details than fit in your short-term memory. The Green Bar stimulates your brain's pleasure center,
I like Red. I prefer the state where I have a broken test.
like playing a slot machine in a casino, except with test-first you always win. This stimulation propels Flow, and reinforces your mental image. But the Bar's stimulating color might not always be Green. Sometimes you expect an assertion to fail, forcing code changes. To test our tests, in the negative, we must write an assertion we expect to fail, and then hit the test button. When adding the code, we expect the test to immediately pass. When refactoring, we make the smallest change we can before testing, and we expect a pass. Our expectations channel intent into the code. To reinforce, each time you hit the test button think the following, or say it aloud to your pair-programmer: - New structure: "Predict compiler error." - New assertion: "Predict failure." - New code: "Predict success." - Refactoring step: "Predict success."
This is cool. You got any handy weasel phrases for this? I mean a
phrase that could covertly get the process going, that could be
slipped into a conversation without raising an XP Alert.
"Refactoring" and "assertion" are not candidate terms for this.
When writing an assertion and ensuring it fails for the correct reason, you predict a Red Bar, and getting one stimulates Flow. Shared alpha would get induced with this attitude: what if each member of the pair thinks the *pair* might have some information they might need? Individuals plug-in to the pair. No stress there. The good things happen when the pairs are thinking >differently<.
Of course. You mean good things happen when the individuals
constituting the pair are thinking differently. If they were thinking
the same, then they may as well be programming solo, because no new
ideas could arise, no learning could take place, by combining
identical thought patterns.
There is no benefit to applying solo programming ideas, or test-last programming ideas, to the experience of PP with TDD. Specifically, there is no need to design up front, or "agree on a design up front", or even state any kind of long-term goal. Of course if the inspiration or need arises to do those things, do them. But it's perfectly safe to draw a card, pick a pair, and start typing without doing either of them.
Many people will not make this jump when you try to explain the value
of PP to them. With PP at peak performance, you are simply talking
to one brain composed to two individual brains. How does this get rid
of BFUD, inspections, or goals and the rest of the established
practices?
When talking about the value of PP, it's common to hear and say "two heads are better than one", when it is in fact one head. If we were all in Vulcan Mind Meld, then there would be no point. (We'd need to Quad Program to achieve the mental split needed!)
No point to what? I said the common saying, or way to understand the
benefits of PP, transmits a misunderstanding of what PP is.
I guess a simple way for mgrs to induce this is to address the pair, and not the individuals. Why don't they do this? Are they not aware of the power and efficiency (cost savings) of a paired brain? Often you hear the argument that PP would give you instant knowledge transfer and coverage when an individual leaves an organization. This is also inconsistent--pairs are not replaceable by the individuals that formed them. Mgrs will not get a performance continuity benefit any more in PP than with individuals. Don't they need to understand this? The best way for managers to learn this is to see pairs in action. The >extra< best way is to pick managers who don't meddle in details that should be the programmers' responsibilities. All remaining arguments, though sometimes useful, are specious. There are ways to achieve the "team knowledge" benefits without pairing. Some might almost be as cheap as pairing. But >none< of them should be expected to be enough to sway a manager.
If a mgr is going to steer, a mgr needs to know what they are
driving. There appears to be some misunderstanding of that. They
think they have two sedans when they actually have a one 4WD SUV.
Also, a range of challenges comparing the performance of Solo versus
Pair have to be studied. I don't think the entire range has been
accounted for, just small studies of a limited number of tasks.
SOYLENT XP IS PEOPLE!!!
Also, what about an attitude shift: Shared alpha would not get induced with this attitude: what if each member of the pair felt as if the other person might have information that they might need? Too much stress. "Alpha" rhythm is relaxed zoning. We want the human equivalent of the "Theta rhythm" found in animals. This occurs during our dream state, and when we are "in flow", which is when perniciously tracking one subject.
Theta rhythm was found in yogis and zen practitioners...it's the next
bigger wavelength than alpha, read that somewhere.
If your environment permits chronic improvements and positive reinforcement over one current task, without distractions from other tasks, you can enter "Flow". In this zone, every thought connects. When you emerge from Flow and take a break, you may be surprised to find hours have passed. The sun may have set, or dawned; you didn't notice.
Flow may require those conditions, for a relatively brief period, to
get started, but once the flame is going you can be interrupted and
even go home, with some passing unit tests...but you say this below.
XP supports easy starting and maintenance of the flame, where before
it was magic or you had to steal it.
In Flow, your short-term memory maintains an image of your current task. This memory behaves like a CPU's storage cache. Interruptions that replace the cache damage Flow. (Peaks in the intensity of your Flow will often inspire your loved ones, even at long distance, to select that exact moment to interrupt you.)
Wouldn't XP practices be geared for starting and building Flow, even
if you have a life? Ah I see you answer this below...
Our technical goals, TDD and PP, have distinct definitions, so we will know unambiguously when we have them. Our real goal is Flow, a subjective experience.
Flow is objectively measurable.
When you test, between hitting the test button and receiving a Green Bar, the tests should take care of every possible detail that enables your project's success; more details than fit in your short-term memory. The Green Bar stimulates your brain's pleasure center,
I like Red. I prefer the state where I have a broken test.
like playing a slot machine in a casino, except with test-first you always win. This stimulation propels Flow, and reinforces your mental image. But the Bar's stimulating color might not always be Green. Sometimes you expect an assertion to fail, forcing code changes. To test our tests, in the negative, we must write an assertion we expect to fail, and then hit the test button. When adding the code, we expect the test to immediately pass. When refactoring, we make the smallest change we can before testing, and we expect a pass. Our expectations channel intent into the code. To reinforce, each time you hit the test button think the following, or say it aloud to your pair-programmer: - New structure: "Predict compiler error." - New assertion: "Predict failure." - New code: "Predict success." - Refactoring step: "Predict success."
This is cool. You got any handy weasel phrases for this? I mean a
phrase that could covertly get the process going, that could be
slipped into a conversation without raising an XP Alert.
"Refactoring" and "assertion" are not candidate terms for this.
When writing an assertion and ensuring it fails for the correct reason, you predict a Red Bar, and getting one stimulates Flow. Shared alpha would get induced with this attitude: what if each member of the pair thinks the *pair* might have some information they might need? Individuals plug-in to the pair. No stress there. The good things happen when the pairs are thinking >differently<.
Of course. You mean good things happen when the individuals
constituting the pair are thinking differently. If they were thinking
the same, then they may as well be programming solo, because no new
ideas could arise, no learning could take place, by combining
identical thought patterns.
There is no benefit to applying solo programming ideas, or test-last programming ideas, to the experience of PP with TDD. Specifically, there is no need to design up front, or "agree on a design up front", or even state any kind of long-term goal. Of course if the inspiration or need arises to do those things, do them. But it's perfectly safe to draw a card, pick a pair, and start typing without doing either of them.
Many people will not make this jump when you try to explain the value
of PP to them. With PP at peak performance, you are simply talking
to one brain composed to two individual brains. How does this get rid
of BFUD, inspections, or goals and the rest of the established
practices?
When talking about the value of PP, it's common to hear and say "two heads are better than one", when it is in fact one head. If we were all in Vulcan Mind Meld, then there would be no point. (We'd need to Quad Program to achieve the mental split needed!)
No point to what? I said the common saying, or way to understand the
benefits of PP, transmits a misunderstanding of what PP is.
I guess a simple way for mgrs to induce this is to address the pair, and not the individuals. Why don't they do this? Are they not aware of the power and efficiency (cost savings) of a paired brain? Often you hear the argument that PP would give you instant knowledge transfer and coverage when an individual leaves an organization. This is also inconsistent--pairs are not replaceable by the individuals that formed them. Mgrs will not get a performance continuity benefit any more in PP than with individuals. Don't they need to understand this? The best way for managers to learn this is to see pairs in action. The >extra< best way is to pick managers who don't meddle in details that should be the programmers' responsibilities. All remaining arguments, though sometimes useful, are specious. There are ways to achieve the "team knowledge" benefits without pairing. Some might almost be as cheap as pairing. But >none< of them should be expected to be enough to sway a manager.
If a mgr is going to steer, a mgr needs to know what they are
driving. There appears to be some misunderstanding of that. They
think they have two sedans when they actually have a one 4WD SUV.
Also, a range of challenges comparing the performance of Solo versus
Pair have to be studied. I don't think the entire range has been
accounted for, just small studies of a limited number of tasks.