Skip to main content
Project Management

Return to Question

Tweeted twitter.com/#!/StackProjects/status/366121053795254272
Clarify question and retrofit for the Q&A format; minor grammatical and semantic edits.
Source Link
Todd A. Jacobs ♦
Todd A. Jacobs ♦
  • 50.7k
  • 7
  • 60
  • 181

Peopleware, the How can my team reconcile flow and the reported benefits of pair programming-programming?

For those of you who have read Peopleware, you were probably exposed to the concept of flow. Flow, is a mental state attained by creativity workers (engineers, writers, programmers, etc.) which is often described as a state of immersion in which time seems to pass unknowingly and creative work flows from the mind. Throughout Peopleware, there is the recurring concept that to engage in flow, privacy and quiet are the main two ingredients.

On the other hand, I have read a substantial body of research in regards to pair programming (which should be familiar to the XP folks reading this). Pair programming, advocates a two person team which functions as an single organic, programming entity to accomplish a single goal. For those of you not acquainted, this paper should help: http://www.cs.utexas.edu/users/downing/papers/PairProgrammingKindergarten2000.pdf

So now we have two slightly contradicting ideas in the realm of software PM which proclaim to increase programmer productivity, code quality, and happiness.

My question to you is, are these ideas reconcilable? Is there any research on this topic, or how have you lead your software teams in regard to this?

EDIT:

The closest scheme that I have seen to bridge this particular kind of paradox is that of a combination. Some of the work is done in pair programming, while some of the work is done in private. How to balance this team/individual work seems to me to be the biggest question in regards to this compromise.

Peopleware, the flow and the reported benefits of pair programming

For those of you who have read Peopleware, you were probably exposed to the concept of flow. Flow, is a mental state attained by creativity workers (engineers, writers, programmers, etc) which is often described as a state of immersion in which time seems to pass unknowingly and creative work flows from the mind. Throughout Peopleware, there is the recurring concept that to engage in flow, privacy and quiet are the main two ingredients.

On the other hand, I have read a substantial body of research in regards to pair programming (which should be familiar to the XP folks reading this). Pair programming, advocates a two person team which functions as an single organic, programming entity to accomplish a single goal. For those of you not acquainted, this paper should help: http://www.cs.utexas.edu/users/downing/papers/PairProgrammingKindergarten2000.pdf

So now we have two slightly contradicting ideas in the realm of software PM which proclaim to increase programmer productivity, code quality and happiness.

My question to you is, are these ideas reconcilable? Is there any research on this topic, or how have you lead your software teams in regard to this?

EDIT:

The closest scheme that I have seen to bridge this particular kind of paradox is that of a combination. Some of the work is done in pair programming, while some of the work is done in private. How to balance this team/individual work seems to me to be the biggest question in regards to this compromise.

How can my team reconcile flow and pair-programming?

For those of you who have read Peopleware, you were probably exposed to the concept of flow. Flow is a mental state attained by creativity workers (engineers, writers, programmers, etc.) which is often described as a state of immersion in which time seems to pass unknowingly and creative work flows from the mind. Throughout Peopleware, there is the recurring concept that to engage in flow, privacy and quiet are the main two ingredients.

On the other hand, I have read a substantial body of research in regards to pair programming (which should be familiar to the XP folks reading this). Pair programming, advocates a two person team which functions as an single organic, programming entity to accomplish a single goal. For those of you not acquainted, this paper should help: http://www.cs.utexas.edu/users/downing/papers/PairProgrammingKindergarten2000.pdf

So now we have two slightly contradicting ideas in the realm of software PM which proclaim to increase programmer productivity, code quality, and happiness.

My question to you is, are these ideas reconcilable? Is there any research on this topic, or how have you lead your software teams in regard to this?

EDIT:

The closest scheme that I have seen to bridge this particular kind of paradox is that of a combination. Some of the work is done in pair programming, while some of the work is done in private. How to balance this team/individual work seems to me to be the biggest question in regards to this compromise.

Source Link
Alexander Ventura
Alexander Ventura
  • 183
  • 4

Peopleware, the flow and the reported benefits of pair programming

For those of you who have read Peopleware, you were probably exposed to the concept of flow. Flow, is a mental state attained by creativity workers (engineers, writers, programmers, etc) which is often described as a state of immersion in which time seems to pass unknowingly and creative work flows from the mind. Throughout Peopleware, there is the recurring concept that to engage in flow, privacy and quiet are the main two ingredients.

On the other hand, I have read a substantial body of research in regards to pair programming (which should be familiar to the XP folks reading this). Pair programming, advocates a two person team which functions as an single organic, programming entity to accomplish a single goal. For those of you not acquainted, this paper should help: http://www.cs.utexas.edu/users/downing/papers/PairProgrammingKindergarten2000.pdf

So now we have two slightly contradicting ideas in the realm of software PM which proclaim to increase programmer productivity, code quality and happiness.

My question to you is, are these ideas reconcilable? Is there any research on this topic, or how have you lead your software teams in regard to this?

EDIT:

The closest scheme that I have seen to bridge this particular kind of paradox is that of a combination. Some of the work is done in pair programming, while some of the work is done in private. How to balance this team/individual work seems to me to be the biggest question in regards to this compromise.