UnderstandingqP
airqProgra
mm
ing:qT
heqBaseqLa
yerS
tephanqS
alingerq•qLutzqP
rechelt
StephanqSalingerq•qLutzqPrechelt
UnderstandingqPairqProgramming:
TheqBaseqLayerThereq hasq beenq andq stillq isq aq lotq ofq controversyq onq whetherq pairqprogrammingqisqaqusefulqengineeringqtechniqueq–qasqifqthisqwouldqnotqstronglyqdependqonqtheqspecificqgoals,qtask,qandqtheqpair-sqpairqprogrammingq skill.q Ratherq thanq providingq stillq moreq bottom-line,qquantitativeq resultsq onq pairq programming,q aq researchq groupq atqFreieqUniversitätqBerlinqsetqoutqtoqdecipher
–qwhatqisqtheqactualqprocessqofqpairqprogrammingqand
–qwhatqisqpairqprogrammingqskill.
Thisq bookq providesq aq setq ofq conceptsq thatq servesq asq theqinfrastructureq forq studiesq ofq pairq programmingq thatq focusq onqqualitativeq dataq analysis.q q Itq promisesq toq connectq theq resultsq ofqsuchqstudiesqtoqoneqanother.
Theq bookq isq orientedq towardsq researchersq only,q notq towardsqpractitioners.
StephanqSalingerq•qLutzqPrechelt
UnderstandingqPairqProgramming:qTheqBaseqLayer
9 783732 281930
The Deutsche Nationalbibliothek lists this publication in theDeutsche Nationalbibliographie:http://dnb.d-nb.de
Stephan Salinger, Lutz Prechelt:Understanding Pair Programming: The Base Layer
Typeset with LaTeX in Palatino fontPublished and printed by:BoD — Books on Demand, Norderstedt, Germanywww.bod.de
ISBN 978-3-7322-8193-0
c© Copyright 2013 by Stephan Salinger and Lutz Prechelt
This work is licensed under a Creative CommonsAttribution–NonCommercial–NoDerivatives 4.0 International LicenseCC BY–NC–ND 4.0http://creativecommons.org/licenses/by-nc-nd/4.0/
Dear reader, you can get a printed copy of this book athttp://www.amazon.co.uk, but, due to a publishing mishap,not at http://www.amazon.com. We are sorry for any inconvenience!
Stephan Salinger • Lutz Prechelt
Understanding
Pair Programming:The Base Layer
Freie Universität Berlin
Contents
Contents 5
I Introduction 15
1 Introduction 171.1 Pair programming . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.1 What is pair programming? . . . . . . . . . . . . . . . . . 181.1.2 Is pair programming advantageous? . . . . . . . . . . . . 19
1.2 Current understanding of pair programming . . . . . . . . . . . 191.3 The data used for this book . . . . . . . . . . . . . . . . . . . . . 20
1.3.1 Session BA1 . . . . . . . . . . . . . . . . . . . . . . . . . . 211.3.2 Session CA2 . . . . . . . . . . . . . . . . . . . . . . . . . . 221.3.3 Session ZB7 . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.4 Our research perspective . . . . . . . . . . . . . . . . . . . . . . . 221.4.1 Basic research perspective: Understanding programming 221.4.2 Practitioner perspective: Using pair programming . . . . 231.4.3 Overall research approach: Work in “layers” . . . . . . . 231.4.4 Research method: Grounded Theory Methodology . . . 241.4.5 On using prior research results . . . . . . . . . . . . . . . 26
1.5 About this book . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271.5.1 What this book is . . . . . . . . . . . . . . . . . . . . . . . 271.5.2 What this book is not . . . . . . . . . . . . . . . . . . . . . 281.5.3 How to read this book . . . . . . . . . . . . . . . . . . . . 291.5.4 How to start performing research based on this book . . 29
1.6 Terminology and notation . . . . . . . . . . . . . . . . . . . . . . 31
2 Overview of the base layer 352.1 What are the base concepts? . . . . . . . . . . . . . . . . . . . . . 35
2.1.1 Concepts and concept classes . . . . . . . . . . . . . . . . 362.1.2 HHI concepts vs. HCI/HEI concepts vs. supplementary
concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362.1.3 HHI concept class groupings . . . . . . . . . . . . . . . . 36
2.2 What is the base layer? . . . . . . . . . . . . . . . . . . . . . . . . 372.3 Key decisions for the base layer . . . . . . . . . . . . . . . . . . . 37
2.3.1 Primarily rely on verbalization . . . . . . . . . . . . . . . 382.3.2 Model illocutionary acts . . . . . . . . . . . . . . . . . . . 38
5
6 Contents
2.3.3 Let segmentation emerge . . . . . . . . . . . . . . . . . . 392.3.4 Crave for behavioristic interpretation . . . . . . . . . . . 392.3.5 Model the discourse world, not the activity world . . . . 402.3.6 Model dialog episodes . . . . . . . . . . . . . . . . . . . . 402.3.7 Design the concepts to reflect relevant phenomena . . . 41
II The HHI concepts:Human/human interaction 43
3 Objects and verbs of the HHI concepts 453.1 The structure and meaning of concept names . . . . . . . . . . . 453.2 The objects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463.3 The verbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 473.4 The existing object/verb combinations . . . . . . . . . . . . . . . 483.5 Types of verbs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 493.6 The notion of “knowledge” . . . . . . . . . . . . . . . . . . . . . 523.7 propose vs. explain . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.8 explain vs. think aloud . . . . . . . . . . . . . . . . . . . . . . . . . 563.9 disagree+propose vs. challenge . . . . . . . . . . . . . . . . . . . . . 57
4 Product-oriented concepts: design 594.1 Topic of design concepts . . . . . . . . . . . . . . . . . . . . . . . 594.2 design concepts and their properties . . . . . . . . . . . . . . . . 60
4.2.1 Types and intentions of proposals . . . . . . . . . . . . . 624.2.2 Referring to editing steps . . . . . . . . . . . . . . . . . . 634.2.3 Proposals with rationale . . . . . . . . . . . . . . . . . . . 644.2.4 decide vs. agree . . . . . . . . . . . . . . . . . . . . . . . . . 644.2.5 amend vs. a new propose . . . . . . . . . . . . . . . . . . . 644.2.6 amend or challenge one’s own proposal . . . . . . . . . . . 644.2.7 Indicating agreement vs. indicating attentiveness . . . . 654.2.8 Short negations . . . . . . . . . . . . . . . . . . . . . . . . 654.2.9 Proposal-less questions . . . . . . . . . . . . . . . . . . . 654.2.10 Restricted disagreement . . . . . . . . . . . . . . . . . . . 66
4.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 664.3.1 propose_design vs. ask_knowledge . . . . . . . . . . . . . . . 664.3.2 *_design vs. explain_knowledge/explain_finding . . . . . . . 664.3.3 propose_design vs. propose_step/propose_todo . . . . . . . . 67
5 Product-oriented concepts: requirement 695.1 Topic of requirement concepts . . . . . . . . . . . . . . . . . . . . 695.2 requirement concepts and their properties . . . . . . . . . . . . . 70
5.2.1 remember_requirement . . . . . . . . . . . . . . . . . . . . . 715.2.2 propose_requirement . . . . . . . . . . . . . . . . . . . . . . 71
Contents 7
5.2.3 agree_requirement and challenge_requirement . . . . . . . . 715.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 72
6 Process-oriented concepts: step 736.1 Topic of step concepts . . . . . . . . . . . . . . . . . . . . . . . . . 736.2 step concepts and their properties . . . . . . . . . . . . . . . . . . 75
6.2.1 propose_step with rationale . . . . . . . . . . . . . . . . . . 756.2.2 Purpose of making propose_step utterances . . . . . . . . 766.2.3 Reserving time . . . . . . . . . . . . . . . . . . . . . . . . 776.2.4 Imprecise proposals . . . . . . . . . . . . . . . . . . . . . 776.2.5 decide_step vs. agree_step . . . . . . . . . . . . . . . . . . . 786.2.6 amend, challenge, or disagree one’s own proposal . . . . . 786.2.7 Indicating agreement vs. indicating attentiveness . . . . 796.2.8 ask_step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 796.3.1 *_step vs. explain_knowledge/explain_finding . . . . . . . . 796.3.2 propose_step vs. propose_design . . . . . . . . . . . . . . . . 796.3.3 propose_step vs. ask_knowledge . . . . . . . . . . . . . . . . 816.3.4 ask_step vs. ask_knowledge . . . . . . . . . . . . . . . . . . 826.3.5 ask_step vs. ask_design . . . . . . . . . . . . . . . . . . . . 826.3.6 disagree_step vs. explain_knowledge/explain_finding . . . . 826.3.7 amend_step vs. explain_knowledge/explain_finding . . . . . 82
7 Process-oriented concepts: completion 837.1 Topic of completion concepts . . . . . . . . . . . . . . . . . . . . . 837.2 completion concepts and their properties . . . . . . . . . . . . . . 84
7.2.1 Short evaluations . . . . . . . . . . . . . . . . . . . . . . . 847.2.2 Indirect evaluations . . . . . . . . . . . . . . . . . . . . . 857.2.3 Evaluation of quality . . . . . . . . . . . . . . . . . . . . . 85
7.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 85
8 Process-oriented concepts: todo 878.1 Topic of todo concepts . . . . . . . . . . . . . . . . . . . . . . . . . 878.2 todo concepts and their properties . . . . . . . . . . . . . . . . . . 888.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 89
8.3.1 propose_todo vs. propose_step . . . . . . . . . . . . . . . . . 898.3.2 propose_todo vs. explain_knowledge/explain_finding . . . . 908.3.3 propose_todo vs. amend_design/propose_design . . . . . . . 90
9 Process-oriented concepts: strategy 939.1 Topic and typology of strategy concepts . . . . . . . . . . . . . . 93
9.1.1 OWP: Organizing Work Packages . . . . . . . . . . . . . 939.1.2 DPR: Determining Procedure Rules . . . . . . . . . . . . 939.1.3 EXS: Expanding a step into a strategy . . . . . . . . . . . . 94
8 Contents
9.1.4 Extensional vs. intensional representation . . . . . . . . . 949.1.5 Range . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 949.1.6 Mixed types . . . . . . . . . . . . . . . . . . . . . . . . . . 95
9.2 strategy concepts and their properties . . . . . . . . . . . . . . . . 969.2.1 Proposal mode . . . . . . . . . . . . . . . . . . . . . . . . 969.2.2 Proposals with alternatives . . . . . . . . . . . . . . . . . 969.2.3 decide_strategy vs. agree_strategy . . . . . . . . . . . . . . . 969.2.4 Secondary issues . . . . . . . . . . . . . . . . . . . . . . . 969.2.5 Forms of amend_strategy . . . . . . . . . . . . . . . . . . . 979.2.6 Distinguishing proposals: amend, challenge, propose . . . . 989.2.7 ask_strategy . . . . . . . . . . . . . . . . . . . . . . . . . . 999.2.8 agree_strategy . . . . . . . . . . . . . . . . . . . . . . . . . 999.2.9 disagree_strategy . . . . . . . . . . . . . . . . . . . . . . . . 99
9.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 999.3.1 *_strategy vs. explain_knowledge/explain_finding . . . . . . 999.3.2 propose_strategy vs. propose_todo . . . . . . . . . . . . . . . 999.3.3 propose_strategy vs. propose_step . . . . . . . . . . . . . . . 100
9.3.3.1 Recycled strategies . . . . . . . . . . . . . . . . 1009.3.3.2 step with forward reference . . . . . . . . . . . . 1009.3.3.3 steps aiming at advantage . . . . . . . . . . . . . 1009.3.3.4 Multi-part proposals not forming a strategy . . 1019.3.3.5 The creative act is invisible . . . . . . . . . . . . 1019.3.3.6 Lowly creative acts . . . . . . . . . . . . . . . . 101
9.3.4 propose_strategy vs. propose_design . . . . . . . . . . . . . 1019.3.5 agree_strategy vs. agree_knowledge . . . . . . . . . . . . . . 1029.3.6 ask_strategy vs. ask_knowledge . . . . . . . . . . . . . . . . 1039.3.7 ask_strategy vs. ask_step . . . . . . . . . . . . . . . . . . . . 103
10 Process-oriented concepts: state 10510.1 Topic of state concepts . . . . . . . . . . . . . . . . . . . . . . . . 10510.2 state concepts and their properties . . . . . . . . . . . . . . . . . 106
10.2.1 Short agree utterances . . . . . . . . . . . . . . . . . . . . 10610.2.2 Lack of reference to a strategy . . . . . . . . . . . . . . . . 10610.2.3 Partial disagreement . . . . . . . . . . . . . . . . . . . . . 107
10.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 10710.3.1 explain_state vs. explain_completion . . . . . . . . . . . . . 10710.3.2 explain_state vs. explain_finding . . . . . . . . . . . . . . . 107
11 Universal concepts: What is “knowledge”? 10911.1 On knowledge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10911.2 The base concepts’ notion of knowledge . . . . . . . . . . . . . . 11011.3 Priority rules for assigning knowledge concepts . . . . . . . . . 111
12 Universal concepts: finding 113
Contents 9
12.1 Topic and typology of finding concepts . . . . . . . . . . . . . . . 11312.1.1 finding type P: perceived event . . . . . . . . . . . . . . . 11412.1.2 finding type D: discovered issue . . . . . . . . . . . . . . . 11412.1.3 finding type T: thought . . . . . . . . . . . . . . . . . . . . 11612.1.4 Priority rules for checking finding types . . . . . . . . . . 11612.1.5 finding type indicators and examples . . . . . . . . . . . . 117
12.2 finding concepts and their properties . . . . . . . . . . . . . . . . 12012.2.1 Aggregation of utterances . . . . . . . . . . . . . . . . . . 12012.2.2 Repeated statements . . . . . . . . . . . . . . . . . . . . . 12112.2.3 Thinking aloud . . . . . . . . . . . . . . . . . . . . . . . . 12112.2.4 Revoking and replacing findings . . . . . . . . . . . . . . 12212.2.5 “Additional” findings . . . . . . . . . . . . . . . . . . . . 12212.2.6 Justifications of proposals . . . . . . . . . . . . . . . . . . 12512.2.7 Justifications of findings . . . . . . . . . . . . . . . . . . . 12512.2.8 disagree_finding, challenge_finding . . . . . . . . . . . . . . 12512.2.9 Reasons for agreement . . . . . . . . . . . . . . . . . . . . 12712.2.10 Doubt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12812.2.11 ask_finding? . . . . . . . . . . . . . . . . . . . . . . . . . . 128
12.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 12912.3.1 finding vs. other universal concepts . . . . . . . . . . . . 13012.3.2 explain_finding vs. propose_design . . . . . . . . . . . . . . 13012.3.3 explain_finding vs. *_step . . . . . . . . . . . . . . . . . . . 13012.3.4 explain_finding vs. explain_completion or explain_state . . . 130
13 Universal concepts: hypothesis 13113.1 Topic of hypothesis concepts . . . . . . . . . . . . . . . . . . . . . 131
13.1.1 Uncertain knowledge . . . . . . . . . . . . . . . . . . . . 13113.1.2 Hard-to-verify assumptions . . . . . . . . . . . . . . . . . 13113.1.3 Readily verifiable conjectures . . . . . . . . . . . . . . . . 13213.1.4 Issue types addressed by hypotheses . . . . . . . . . . . 132
13.2 hypothesis concepts and their properties . . . . . . . . . . . . . . 13313.2.1 propose_hypothesis . . . . . . . . . . . . . . . . . . . . . . . 13313.2.2 agree_hypothesis, disagree_hypothesis, challenge_hypothesis . 13313.2.3 Conditional agreement . . . . . . . . . . . . . . . . . . . . 13413.2.4 Revoking or replacing one’s own hypothesis . . . . . . . 13413.2.5 amend_hypothesis: One hypothesis or several? . . . . . . . 13413.2.6 Justification of hypotheses . . . . . . . . . . . . . . . . . . 13613.2.7 Justification by hypotheses . . . . . . . . . . . . . . . . . 136
13.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 13613.3.1 propose_hypothesis vs. explain_finding . . . . . . . . . . . . 136
14 Universal concepts: standard of knowledge 13914.1 Topic of standard of knowledge concepts . . . . . . . . . . . . . . . 139
14.1.1 PT: Preparing knowledge transfer . . . . . . . . . . . . . 139
10 Contents
14.1.2 RT: Refusing knowledge transfer . . . . . . . . . . . . . . 14014.1.3 AT: Acknowledging knowledge transfer . . . . . . . . . . 140
14.2 standard of knowledge concepts and their properties . . . . . . . . 14114.2.1 ask_standard of knowledge . . . . . . . . . . . . . . . . . . . 14114.2.2 AT with paraphrasing . . . . . . . . . . . . . . . . . . . . 14114.2.3 standard of knowledge in the making . . . . . . . . . . . . . 14214.2.4 explain_standard of knowledge may be findings . . . . . . . 14314.2.5 Limited-knowledge proposals . . . . . . . . . . . . . . . 14314.2.6 Implicit statements . . . . . . . . . . . . . . . . . . . . . . 14314.2.7 Backward-looking statements . . . . . . . . . . . . . . . . 14314.2.8 Signaling ongoing thinking . . . . . . . . . . . . . . . . . 144
14.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 14414.3.1 explain_standard of knowledge vs. ask_knowledge . . . . . . 14414.3.2 explain_standard of knowledge vs. agree_finding or disagree_
finding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14414.3.3 explain_standard of knowledge vs. explain_finding . . . . . . 14514.3.4 explain_standard of knowledge vs. agree/disagree for a pro-
posal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14514.3.5 explain_standard of knowledge vs. propose_hypothesis . . . . 145
15 Universal concepts: gap in knowledge 14715.1 Topic of gap in knowledge concepts . . . . . . . . . . . . . . . . . . 14715.2 gap in knowledge concepts and their properties . . . . . . . . . . . 148
15.2.1 explain_gap in knowledge . . . . . . . . . . . . . . . . . . . 14815.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 148
15.3.1 explain_gap in knowledge vs. explain_standard of knowledge 14815.3.2 agree_gap in knowledge vs. agree_standard of knowledge . . . 14815.3.3 explain_gap in knowledge vs. propose_step . . . . . . . . . . 149
16 Universal concepts: knowledge 15116.1 Topic of knowledge concepts . . . . . . . . . . . . . . . . . . . . . 15116.2 knowledge concepts and their properties . . . . . . . . . . . . . . 153
16.2.1 Evaluations and judgments . . . . . . . . . . . . . . . . . 15316.2.2 Unprompted knowledge transfer . . . . . . . . . . . . . . 15416.2.3 Rhetorical questions . . . . . . . . . . . . . . . . . . . . . 15416.2.4 Aggregation of utterances . . . . . . . . . . . . . . . . . . 15416.2.5 amend_knowledge? . . . . . . . . . . . . . . . . . . . . . . . 15416.2.6 “Different” answers . . . . . . . . . . . . . . . . . . . . . 15416.2.7 Modes of agreement . . . . . . . . . . . . . . . . . . . . . 15516.2.8 Indicating agreement vs. indicating attentiveness . . . . 15716.2.9 Opposition and controversy . . . . . . . . . . . . . . . . . 15716.2.10 Disagreeing by agreeing to the opposite . . . . . . . . . . 15816.2.11 Opinions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15816.2.12 Limited conviction . . . . . . . . . . . . . . . . . . . . . . 158
Contents 11
16.2.13 ask_knowledge is not always that . . . . . . . . . . . . . . 15816.2.14 Questions including possible answers . . . . . . . . . . . 15816.2.15 Statement or question? . . . . . . . . . . . . . . . . . . . . 158
16.3 Discrimination from similar concepts . . . . . . . . . . . . . . . . 15916.3.1 explain_knowledge vs. propose_step . . . . . . . . . . . . . . 15916.3.2 explain_knowledge vs. propose_design . . . . . . . . . . . . 15916.3.3 explain_knowledge vs. explain_finding . . . . . . . . . . . . 16016.3.4 explain_knowledge vs. amend_finding, challenge_finding, dis-
agree_finding . . . . . . . . . . . . . . . . . . . . . . . . . . 16116.3.5 explain_knowledge vs. agree_design/disagree_design . . . . 16116.3.6 ask_knowledge vs. propose_hypothesis . . . . . . . . . . . . 16116.3.7 ask_knowledge vs. explain_finding . . . . . . . . . . . . . . 16216.3.8 explain_knowledge vs. explain_standard of knowledge . . . . 16216.3.9 ask_knowledge vs. explain_standard of knowledge . . . . . . 16316.3.10 agree_knowledge vs. explain_standard of knowledge . . . . . 163
17 Universal concepts: activity 16517.1 The notion of facade concept class . . . . . . . . . . . . . . . . . 16517.2 Topic of activity concepts . . . . . . . . . . . . . . . . . . . . . . . 16517.3 activity concepts and their properties . . . . . . . . . . . . . . . . 169
17.3.1 Granularity of think aloud_activity . . . . . . . . . . . . . . 16917.3.2 think aloud_activity phenomena leading to questions . . . 17017.3.3 HCI/HEI activities resulting from an utterance . . . . . . 17017.3.4 Disconnect of HCI/HEI activity and verbalization . . . . 17117.3.5 The partner commenting on activity vs. on verbalizations 17117.3.6 challenge_activity . . . . . . . . . . . . . . . . . . . . . . . 17117.3.7 agree_activity, disagree_activity . . . . . . . . . . . . . . . . 17217.3.8 Comments before the fact . . . . . . . . . . . . . . . . . . 17317.3.9 Comments after the end . . . . . . . . . . . . . . . . . . . 17317.3.10 amend_activity vs. challenge_activity . . . . . . . . . . . . . 17317.3.11 stop_activity . . . . . . . . . . . . . . . . . . . . . . . . . . 17417.3.12 Interjections leading to activity change . . . . . . . . . . 17417.3.13 think aloud_activity by the “observer” . . . . . . . . . . . 17417.3.14 Self-criticism . . . . . . . . . . . . . . . . . . . . . . . . . 174
18 Universal concepts: Miscellaneous 17718.1 mumble_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17718.2 say_off topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
III Other concepts 179
19 The HCI/HEI concepts 18119.1 write_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
12 Contents
19.2 search_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18319.3 explore_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18519.4 verify_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18619.5 read_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18919.6 sketch_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18919.7 show_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18919.8 do_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19019.9 On drivers, observers, and co-action . . . . . . . . . . . . . . . . 190
20 Supplementary concepts 19320.1 become_driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19320.2 work in parallel_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . 19320.3 work alone_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19320.4 wait for_sth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19420.5 react to_interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
IV Using the base concepts 195
21 Guidelines for annotating 19721.1 How to pick appropriate HHI concepts . . . . . . . . . . . . . . 19721.2 How to pick appropriate HCI/HEI concepts . . . . . . . . . . . 19821.3 What to consider as context . . . . . . . . . . . . . . . . . . . . . 19921.4 When to use double HHI annotations . . . . . . . . . . . . . . . 19921.5 How to segment utterances . . . . . . . . . . . . . . . . . . . . . 20021.6 How to handle specific phenomena . . . . . . . . . . . . . . . . . 201
21.6.1 How to annotate implicit announcements . . . . . . . . . 20121.6.2 How to annotate thematic shifts . . . . . . . . . . . . . . 20121.6.3 How to annotate repetitions . . . . . . . . . . . . . . . . . 20321.6.4 How to annotate incomplete agreement or disagreement 20421.6.5 How to annotate self-corrections . . . . . . . . . . . . . . 20421.6.6 How to annotate justifications . . . . . . . . . . . . . . . 204
21.7 Method hints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20521.7.1 Step back . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20521.7.2 Paraphrase . . . . . . . . . . . . . . . . . . . . . . . . . . . 20521.7.3 Peek into the future . . . . . . . . . . . . . . . . . . . . . . 206
22 Guidelines for modifying the base concept set 20722.1 What makes a good concept set . . . . . . . . . . . . . . . . . . . 20722.2 When to shift a boundary . . . . . . . . . . . . . . . . . . . . . . 20822.3 When to add a new property value . . . . . . . . . . . . . . . . . 20822.4 When to add a concept and which . . . . . . . . . . . . . . . . . 209
23 Guidelines for creating new concept sets 211
Contents 13
23.1 The idea of layers . . . . . . . . . . . . . . . . . . . . . . . . . . . 21123.2 Granularity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21223.3 Properties and property values . . . . . . . . . . . . . . . . . . . 21223.4 Forming “nice” layers . . . . . . . . . . . . . . . . . . . . . . . . 21323.5 Go! . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Bibliography 215
Index 217
14 Contents
Note
The PDF version of this book contains very many cross-reference hyperlinks.It may be convenient to use the paper version for learning but then the PDFversion for actually working with the base layer.
Acknowledgments
Sincere thanks to Laura Plonka for collecting a large part of our session record-ings and for working closely with Stephan in the early stage of our analysis,to Franz Zieris for the first serious third-party use of the base layer, to FranzZieris, David Socha, and Helen Sharp for their feedback on the book draft, toGesine Milde for proofreading, and to all the pairs that agreed to be recordedand scrutinized.
Part I
Introduction
. . . in which we explain what this book is all about, how to best use it, and whatnotation we will use for the examples.
15
Chapter 1Introduction
This book is a handbook for researchers attempting to make sense of what isgoing on in pair programming sessions; it is based on Stephan Salinger’s Ph.D.dissertation [11]. The present chapter will introduce pair programming (inSection 1.1), summarize what research has so far found out about it (Section 1.2),explain the the raw data we have used (Section 1.3) and the research approachwe propose (Section 1.4), propose how to make use of the book (Section 1.5),and introduce a few key terms and notations (Section 1.6).
1.1 Pair programming
Assume you have a Ph.D. in dancing science and are the only non-programmerat a party full of programmers. According to the stereotype, it is hard to talk tothese people. Your best bet would be to grab two or three of them at once andask
“Is pair programming a good engineering practice?”
The ensuing discussion will be lively and despite talking to techies you canhave your part in the discussion!
Pair programming is a subtle matter and so any good answer to the questionought to begin with “Well. . . ”, but (and that is what makes the discussion solively) many people appear to have a simplified notion of it and a correspond-ingly clear opinion.
Why is that so? And what, exactly, is pair programming anyway?
17
18 Chapter 1. Introduction
1.1.1 What is pair programming?
Pair programming is an old technique. Fred Brooks (of Mythical Man-Monthfame) reports: “Fellow graduate student Bill Wright and I first tried pair program-ming when I was a grad student (1953–56). We produced 1500 lines of defect-freecode; it ran correctly first try.” [15, p.8]. Its modern popularity is largely due toKent Beck’s 1999 book on eXtreme Programming (XP) [2], a holistic method forsmall-team software development consisting of twelve practices, a core one ofwhich is pair programming. In the section on pair programming, Beck states“Pair programming really deserves its own book. It’s a subtle skill” [2, p.100], andindeed such a book appeared in 2002: “Pair Programming Illuminated”. Itoffers the following characterization:
“Pair programming is a style of programming in which two programmerswork side by side at one computer, continually collaborating on the samedesign, algorithm, code, or test. One of the pair, called the driver, istyping at the computer or writing down a design. The other partner, calledthe navigator, has many jobs, one of which is to observe the work of thedriver, looking for tactical and strategic defects.” [15, p.3]
Note that more than half of this definition is concerned with describing theroles of driver and navigator (the latter is now more (Google-)commonly called“observer”). But once you have read this book (or any substantial part of it),you will know that while the first part of the definition is alright, the secondpart is misleading: The description of both roles is wrong in many respects andthe whole driver/observer distinction does not go far in characterizing the pairprogramming process anyway.1
Kent Beck’s description is shorter: “Pair programming—All production code iswritten with two programmers at one machine.” [2, p.54]. There is elaborationlater, but this is arguably his definition of this all-important practice. The 2004second edition of the book is more explicit:
“Write all production programs with two people sitting at one machine.Set up the machine so the partners can sit comfortably side-by-side. Movethe keyboard and mouse back and forth so you are comfortable while you aretyping. Pair programming is a dialog between two people simultaneouslyprogramming (and analyzing and designing and testing) and trying toprogram better.” [3, p.26]
“Sitting comfortably” sounds like trivial information compared to the presum-ably illuminating driver/observer characterization, but it is relevant. And once
1We will occasionally use the terms driver and observer anyway (and without a particularconnotation) when they are handy to express something.
1.2. Current understanding of pair programming 19
you have read the present book, you will appreciate that the above definitioncaptures, very inconspicuously, a key property of pair programming: “Pairprogramming is a dialog”. Yes!
At this point, we have nothing to add to that.
1.1.2 Is pair programming advantageous?
This leaves the other question: Why do some people have such a simplified(and then strong) notion of whether pair programming is a good engineeringpractice? The strongest ones tend to be the strict opponents: their attitudeis usually the belief that the obvious cost of pair programming (occupyingtwo precious software developers rather than just one) is so large that nocorresponding benefits can possibly outweigh it.
More thoughtful discussants will not readily agree because the list of potentialbenefits is impressive. Here is (in paraphrased form) the one presented in “PairProgramming Illuminated” [15, p.4]:
• The resulting code may contain fewer defects.
• The pair will likely finish faster than an individual would.2
• “Pair programmers are happier programmers.”
• Pair programming builds within-team trust and improves teamwork.
• Unless you use fixed pairs only, a developer will become acquainted withlarger fractions of the overall code, design, and requirements.
• Pair partners learn from each other.
How much do we know about which of these are true and to what degree? Notmuch.
1.2 Current understanding of pair programming
Since the pioneering study of Nosek (which appeared even before Kent Beck’sbook) in 1998 [10] there have been many empirical studies on pair program-ming, in particular controlled experiments comparing it to solo programming,but the amount of knowledge produced by these studies is not large; anoverview of research until 2007 is provided by Hannay et al. [8]. We donot aim at a detailed overview here. Roughly speaking, there is good evidencethat pairs tend to be faster than solo programmers, some evidence that their
2The book claims “in about half the time”, but that is oversimplifying matters; see Section 1.2.
20 Chapter 1. Introduction
work tends to have fewer defects, and beginning evidence that the designsproduced are better. The size of each of these effects, however, is hardly under-stood: The results of individual studies differ so much (and those differencesremain unexplained) that taken together the results are inconclusive.
What is worse, their validity is highly questionable as the conditions un-der which most of them were created are highly unrealistic: mostly non-professional programmers, normally non-gelled pairings, usually either devel-opment from scratch or work on fairly small programs, generally little or norelevance of domain knowledge. Even the most ambitious of the controlledexperiments, which hired 295 professionals for one day, concluded: “It is pos-sible that the benefits of pair programming will exceed the results obtained in thisexperiment for larger, more complex tasks and if the pair programmers have a chanceto work together over a longer period of time.” [1]. This statement is also one ofthe few exceptions of the disturbing tendency that most studies tacitly assumethere is no such thing as a specific pair programming skill distinct from generalsoftware development skill. We believe that this assumption is wrong and thatsuccessful pair programming research needs to reflect that. This implies a lotof qualitative pair programming research will be required before meaningfuldesigns for quantitative pair programming studies can even be formulated.
For such qualitative types of research questions, the amount of work doneso far is much smaller3 although the number of questions is larger: There isevidence that different capability levels of the pair members play a role [5]and some evidence that personality characteristics of the pair members mayplay a modest role, too [9]. Only few studies discuss high-level behaviors ormechanisms and those do not do much decomposition or analysis yet, e.g. [6],or are even based on anecdotal evidence only, e.g. [16].
In our view, the most conclusive of the qualitative studies showed that thedescription of the driver and navigator roles from the above definition doesnot represent reality: Rather than working on different levels of abstraction(low and high for the navigator versus medium for the driver) as the definitionassumes, the partners in fact strongly tend to move through these abstractionlevels together [4, 6]. Work towards a more meaningful roles model is still inits infancy [13].
1.3 The data used for this book
The results and all examples presented in this book are based on completerecordings of individual pair programming sessions. The recordings consist ofaudio, a pixel-precise recording of all screen activity, and a webcam recording ofthe pair (usually recorded from atop the monitor). We use Techsmith Camtasia
3We ignore surveys here, because surveys observe attitudes only, not actual practice.
1.3. The data used for this book 21
Studio4 for recording and place the webcam video into the lower-right cornerof the screen video. See [12] for a few more details.
We possess a substantial collection of such recordings of typically one to threehours length. 55 recordings stem from pairs of 48 different volunteer industrialsoftware developers (called A1 to K4, see session descriptions below) doingtheir normal work in their usual environment (domain, code, task, tools, hard-ware, office, etc.) in one of 11 different companies (called A to K). The realitydistortion of these videos is presumably negligible; the pairs do not show (norreport when interviewed afterwards) any acute awareness of being recordedbeyond a minute into their work. The videos reflect a variety of domains,developer constellations, and task types; most tasks can be subsumed underextension programming. They reflect only small cultural variety, though: Allsessions are from German companies and involve German-speaking develop-ers. See the note on translation in Section 1.6.
Further 28 recordings stem from pairs of 56 different volunteer graduate stu-dents (called Z1 to Z56) working in one of 5 different controlled laboratorysettings (called ZA to ZE). The advantage of these recordings is that the re-searcher has a good understanding of the code base, the task, and correctsolutions for the task, making it often much easier to understand what is reallygoing on in the session.
Only 7 of these recordings (6 professional/industrial and 1 student/laboratory)were used for the research reflected here. For the concepts reported here, wereached theoretical saturation (see Section 1.4.4) with only this many.5 Forthe examples presented in this book, we even confine ourselves to only threeof these sessions, so that over time you can get better acquainted with theirrespective topics; some of the examples are even understandably related. Thesethree sessions are the following:
1.3.1 Session BA1
An industrial session (with a duration of 1:47 hours) of two professional pro-grammers B1 and B2 who worked for a large community portal operator Band had paired several times before. They built an extension to the communityportal, which is implemented in PHP. The task difficulty had several aspects
4http://www.techsmith.com/5Actually, most subsets of any random three of them would have sufficed. This will be different
in subsequent research when investigating more specialized pair programming phenomena whichdo not occur frequently, yet still have many facets and variations that need to be understood. Forour purposes here, however, attributes such as the level of programming skill, the amount of pairprogramming experience, the exact nature of the task play, and many others are of minor relevance,as we are concerned only with uncovering phenomena, not with determining their frequency orinterplay.
22 Chapter 1. Introduction
including understanding the design and design rationale of the pre-existingcode, which had been written by nearshore programmers.
1.3.2 Session CA2
An industrial session (duration 1:16 hours) of two professional programmers C2and C5 who worked for a software product company C. The product they workon is a geographic information system (GIS) desktop GUI application written inJava. The design of this software uses abstraction elaborately; the task involvesa small functional extension and its main difficulty lies in understanding andproperly applying the existing design abstractions.
1.3.3 Session ZB7
A laboratory session (duration 2:58 hours) of two graduate students Z19 andZ20 who had worked together as a pair several times before. They built asmall extension to a cleanly designed Java EE web shop system with whichthey were modestly familiar. The main task difficulty lay in the need to applycertain Java EE technologies (JMS, JNDI, JBoss application server) that thedevelopers had learned about in a recent graduate course but had not appliedoften beforehand.
1.4 Our research perspective
The purpose of this book is to lay the groundwork for a stream of research aim-ing at thoroughly understanding pair programming. We will now explain whywe believe this is relevant from the perspective of basic software engineeringresearch (Section 1.4.1) as well as from a practitioner perspective (1.4.2), whatthe overall architecture of this research will look like (1.4.3), which specificresearch method we suggest to primarily use (1.4.4) and what the benefits arewith respect to science’s principle of knowledge accumulation (“standing onthe shoulders of giants”, Section 1.4.5).
1.4.1 Basic research perspective: Understanding programming
Several decades after research began that attempted to understand what isgoing on in the activity we call “programming”, this understanding is still verymuch in its infancy. Pair programming provides a wonderful opportunity formaking a lot of progress there, because rather than having to rely on artificialthink-aloud data gathering techniques, pair programmers verbalize naturallymuch of the time.
Pair programming will surely be different from solo programming in manyrespects, but probably also fundamentally similar. And while think-aloud
1.4. Our research perspective 23
studies may occasionally be possible even in industrial work contexts, theytend to be difficult to arrange. In comparison, pair programming data can begathered more easily and almost uninvasively in industrial work contexts onreal work tasks; see Section 1.3. This whole basic research aspect, however, ismore a fringe benefit, not the core reason why we started this line of work.
1.4.2 Practitioner perspective: Using pair programming
Our overall research goal is to understand the mechanisms of pair program-ming sufficiently well to provide practitioners with detailed advice regarding(a) in which situations to use pair programming and (b) how pair membersmight behave to make pair programming effective, smooth, and efficient.
The basic idea for achieving this is to understand many sub-behaviors at workwithin pair programming and formulate this understanding into one or morepatterns or antipatterns of behavior for each. This research will be almostpurely qualitative; better quantitative research can then be started based onthis differentiated and advanced understanding.
1.4.3 Overall research approach: Work in “layers”
The goals described in Sections 1.4.1 and 1.4.2 are far too ambitious for a singleresearch project; the work needs to be modularized somehow. This, however,will not be easy: Initially, many fundamentals need to be understood beforeeven the first few useful patterns will emerge. Later on, of the various topicsstudied, many will be interdependent or at least layered on top of each other.
Our overall approach is therefore to first lay a foundation of elementary con-cepts useful for analyzing and understanding pair programming sessions. Thisis what the current book is about. We call this foundation the base layer. Itconsists of a set of base concepts (surprisingly called the base concept set andintroduced in Chapters 3 to 20) and rules for its use (Chapter 21) and extension(Chapter 22).
On top of this foundation, a subsequent study of some pair programmingtopic X (such as “decision-making”) can then build an X-layer of concepts thattogether characterize X. While working on the X-layer, the study can make useof the base layer and of the concepts found in subsequent studies performedearlier on other topics A, B, C (say, “pair programming roles” and others). If,for understanding X, some other topic Y (say, “knowledge transfer”) is relevant,the study on X will obtain a minimal understanding of Y required internallybut needs not work it out fully.
Once the study of Y has been performed later (which may also use the X-layer fully), the X-layer can be consolidated into also using the Y-layer. Thiswill break the layering for the overall results (pair programming is a holistic
24 Chapter 1. Introduction
activity after all!), but still keeps a convenient mostly-layered work style forthe individual sub-studies.
Each such study may provide a number of behavioral patterns and antipatterns.The role of the base layer is special because it provides common terminologythat not only jumpstarts but also connects the other studies such as to forma whole rather than a set of separate pieces. The number of concepts in thebase layer is sufficiently small to allow the various researchers to stay on top ofthem, so there are good chances of actual (near-)consistency between studieseven of different researchers rather than only formal pseudo-consistency.
1.4.4 Research method: Grounded Theory Methodology
When we started with this work, we felt that many of the common statementsmade about pair programming were likely misleading or at least naive, but wehad no expectation of what a better characterization would be like. We sharedKent Beck’s view that pair programming is “a subtle skill”. So once we had madethe decision to analyze session recordings such as those described in Section 1.3,we had no idea which aspects of them would be relevant: The dialog content?Its wording? Phrasing? Intonation? Screen content? Changes of screen content?Human activity on the computer? Gestures? Facial expressions? The list wenton and on. We quickly decided it would be important to pick a research methodthat was as empty of assumptions as possible.
Ethnographical approaches are rather far away from software engineeringthinking, so we decided for Grounded Theory Methodology (GTM) [14] as ourbasic research approach. We selected the Straussian variety because we expectits higher degree of structuredness to be more appealing to software engineerscompared to the Glaser style – and we believe that both methods, if understoodcorrectly, will lead to similarly valuable results.
We will not give a primer on Grounded Theory Methodology here. If you havenot used GTM before, you might want to get a textbook about it and read itup; there are a number of such books. The Strauss/Corbin book (or its secondedition but preferably not the third) is a possibility although other books maybe easier to work with. To summarize it in a nutshell, GTM suggests to workas follows:
• GTM work aims at a conceptual explanation (theory) of some phenomenon ofinterest for which each element of the explanation (called a concept or category;we will only use the former term) is directly connected to one or more rawobservations (grounding).
• Formulate your research interest. In our case this was “Define the elementarybehaviors which constitute pair programming.”6 The research question is allowed
6Note this aims only at elements of a theory, not the theory itself and hence requires not all
1.4. Our research perspective 25
to drift freely during GTM work.
• Obtain some observation data. In our case this was the first handful of sessionrecordings. GTM work does not require to pre-plan the data collection norto achieve any kind of representativeness. Additional data will be collectedonce the researcher has found for what sub-phenomena more data is needed(theoretical sampling). For instance, a study of knowledge transfer in pair pro-gramming might find that the general knowledge level difference within thepair appears to be highly relevant. If no recording of an expert working witha true novice is yet available, the researcher would look for such a contextand make a recording there. Representativeness is not required because GTMresults focus on explaining things that exist, not on making claims about theirfrequency.
• Work through the observation data and annotate labels to phenomena thatappear “interesting” with respect to the research focus. You need theoretical sen-sitivity to select relevant phenomena and appropriate labels. The phenomenoncan be anything and of any granularity. Each label is the name of a (prelim-inary) concept; see Chapters 4 to 20 for examples. It is meant to be reused inseveral places in the data. Each concept is chosen such as to help explain someaspect of the phenomenon (theoretical coding). This process is called open coding.
• When assigning the same label again, make sure the phenomena are similarso that you will obtain a consistent concept. To do so, compare to all previousannotations of this concept (constant comparison), determine the commonalities,and record them in a memo. Make sure your concept assignment is fullygrounded, that is, is based only on phenomena actually present in your data, noton any prior knowledge you might have (or rather: assume). The ungroundeduse of any prior assumption when assigning a concept is called forcing.
• If the differences between phenomena annotated with the same conceptappear relevant, represent them by auxiliary concepts: attributes (properties)and attribute values (also properties); apply constant comparison and memoingto them as well. This process is called dimensionalization. Avoid forcing.
• If you have accumulated enough isolated concepts, start discovering relevantrelationships between concepts and validate them for specific phenomena. Therelationships may pertain to context factors, constraints, causes, effects, theactor’s strategies, etc. This process is called axial coding and should also involveconstant comparison as well as a lot of memoing. Avoid forcing. Meanwhile,open coding continues as well.
• If you have accumulated enough relationships, determine the core of thesubject matter and extract those concepts around it that allow to formulate
components of the GTM. Only subsequent studies will aim at actual theories of (some aspects of)pair programming.
26 Chapter 1. Introduction
a narrative (grounded theory) that explains what is going on around this coreconcept. This process is called selective coding. Beware of forcing! Selectivecoding can start as soon as you have the first idea for it and should start nolater than when you find you are detecting only known concepts, not creatingnew ones (theoretical saturation). Selective coding will often point out gaps inyour conceptualization and hence trigger theoretical sampling, in particular ifyou start it early.
Working in this manner (with mostly open coding, some dimensionalization, alittle axial coding, and no selective coding) and considering all of the above-mentioned aspects of the data, we were initially totally overwhelmed by theamount of information residing in our recordings. To cope with this, wedeveloped several additions to plain GTM (see [12] for details), in particular:
• A perspective on the data: GTM suggests to initially conceptualize “every-thing” that may be of relevance and only start focussing on fewer conceptsduring selective coding. This approach does not work for data as rich as ourswith a research question as open as ours. We decided early on that we wouldneed to constrain ourselves to behavioristic concepts as much as possible (seeSection 2.3.4 for details) and soon thereafter to conceptualize verbal interactionin far more detail than other behaviors (see Section 2.3.1).
• Structured concept names to further constrain and structure the applica-ble concept universe in order to make it manageable. See Section 2.1.1 andSection 3.1 for details.
• Pair conceptualizing: Doing GTM in pairs (which we originally called paircoding) helps to quickly weed out or improve inadequate conceptualizations,in particular early in a study when the concept set is still small and hence opento a multitude of possible additions, including additions that lead astray. Thispractice can save inordinate amounts of time and frustration.
• Furthermore, most GTM books recommend transcribing the data but ade-quate transcription of hour-long audio/video data that is as fine-grained andfeature-rich as ours is hardly practical. So we annotate these data directly(without transcription) in the ATLAS.ti7 data analysis software.
1.4.5 On using prior research results
When doing GTM, knowing a lot about your phenomenon in advance is amixed blessing: On the one hand, such prior knowledge can greatly enhanceyour theoretical sensitivity and hence speed up the research process a lot. Onthe other hand, it can lead to forcing and thus ruin the validity of your resultsif you are not careful.
7http://en.wikipedia.org/w/index.php?title=Atlas.ti&oldid=559282786
1.5. About this book 27
The solution suggested by (in particular Glaserian) GTM is to treat all sourcesof such prior knowledge (even if you have written them up yourself!) asadditional observations – of a very different kind, but still to be considered.This idea is called all is data.
For the derivation of the base concept set, we were afraid of forcing and sohave chosen to err on the side of knowing too little rather than too much (or thewrong things). So we started from the epistemological8 stance of Pragmatism9
(very roughly speaking: knowledge should be considered true if it leads tosatisfactory results when applied in the world), hoped that we would havesufficient talent for abductive reasoning10 to invent helpful concepts, wentahead, and read up on related work only after we had found and conceptualizedthe respective phenomena. The most important example of this is the notionof an illocutionary act (see Section 2.3.2) which we developed (and validatedas consistent) in constant comparison manner before we searched for it in theliterature, found it (as a central idea of speech act theory), and hence convincedourselves that the approach was probably sound and valuable.
But this approach can obviously not continue if we are to use the overallresearch approach outlined in Section 1.4.3: If subsequent studies build ontop of the base layer, this will involve using prior assumptions (in form of thebase concepts) and obviously creates a danger of forcing. The danger is smallbecause the concepts are grounded in data from the very domain. Also, thebase layer safeguards against this danger by pointing out in many places thatmodifying certain details of individual concepts may be sensible in subsequentstudies and by providing guidelines for how to do that in an orderly fashion;see Chapter 22 for details.
1.5 About this book
1.5.1 What this book is
• This book aims at providing a foundation for qualitative research into pairprogramming; research that aims at explaining the pair programmingprocess.
• As this foundation, this book introduces and explains the base layer ofconcepts for understanding basic events in pair programming sessions.11
The base layer consists of the base concept set plus rules for its use.
8http://en.wikipedia.org/w/index.php?title=Epistemology&oldid=5659951529http://en.wikipedia.org/w/index.php?title=Pragmatism&oldid=567854814
10http://en.wikipedia.org/w/index.php?title=Abductive_reasoning&oldid=
56294905311Additional discussion can be found in [11].
28 Chapter 1. Introduction
Subsequent studies can build on this to create higher-level concepts andeventually theory.
• The base layer has two goals:
– Helping a pair programming researcher to make faster progresswith any one study.
– Helping the pair programming research community to producestudies the results of which are compatible and that can easily berelated to one another.
• This book explains each concept or concept class via a combination of(1) abstract definition (by means of prototypical properties that instancesof each concept will usually share), (2) ostensive definition (by means ofcontextualized examples such as Example 3.1, Example 8.2), and (3) sep-arate discussion of the delineation between pairs or tuples of conceptswhere the definition is not obvious from (1)+(2) alone.
• This book is a handbook for researchers (as opposed to a textbook). Tomake practical work handy, it is full of cross reference hyperlinks andoften prefers hyperlinks to good Wikipedia articles over references tomore scholarly12-looking paper-based sources – you can find such sourcesin the Wikipedia articles.
We guess that the base concepts may also be helpful when investigating typesof technical pair work other than pair programming, even outside the softwaredomain.
1.5.2 What this book is not
• This book does not contain advice for pair programming practitioners.
• This book does not contain a theory (complete or partial) of pair program-ming.
• This book does not provide a coding scheme (see Section 2.1).
• This book introduces no concepts for which we have never seen instancesin our research data (but accurately grounded concepts only).
• This book provides (almost) no introduction into the qualitative researchmethod we suggest to use (Grounded Theory Methodology).
12We would have liked to make this word a link to the “scholarly method”13 Wikipedia article.Unfortunately, that article does not have good quality, so we do not.
1.5. About this book 29
• This book provides only little description of the research process by whichwe have arrived at the concepts explained herein. Refer to [11] if youneed more detail.
1.5.3 How to read this book
Since we consider this book a handbook, not a textbook, there is no need toread it in full. Rather, you should develop a good understanding of its basicideas and then consult it whenever a decision is unclear that arises in yourresearch work. Here is a proposal how to develop your understanding of thebasic ideas:
1. Read chapters 1 to 3 to obtain an overall orientation of how it all works.
2. Read the introduction and first subsection of each of the chapters 4 to17 to deepen your understanding of the major concept classes and theirdistinction. As you go, take note which of them you find most interestingor intriguing.
3. Now pick the two most intriguing concept classes and read the respectivetwo chapters in full in order to appreciate the subtlety of discriminatingthe concepts consistently. Study the examples thoroughly. Follow someof the cross references to get a feel for the hypertext character of the book.Make use of the index a few times, e.g. to locate additional examples ordiscussion involving a particular concept.
4. Read the introduction of Chapter 19 and skim at least its subsections19.2, 19.3, and 19.4 to understand the non-dialog-oriented part of the baseconcept set.
5. For sake of completeness, have a short look at chapters 18 and 20.
6. Skim chapters 21 to 23.
An alternative method would be to start off to read the whole book, but thenskip to the beginning of the next chapter whenever you get bored or over-whelmed.
Done? Congrats! You are now ready to go with your own base-layer-basedpair programming research.
1.5.4 How to start performing research based on this book
To give you a rough idea how research based on this book might proceed, weprovide a short sketch for your first attempts here. You should develop yourown style over time.
30 Chapter 1. Introduction
1. Learn about the base layer by following the instructions in Section 1.5.3.
2. Formulate your research question.
3. Obtain a handful of recordings of pair programming sessions. If thephenomena you investigate are frequent, three to five recordings will besufficient in the beginning; you can get additional ones later once youhave a better idea what you are looking for (theoretical sampling).
4. Exercise with the base layer, for example by fully annotating all base con-cepts that apply to at least a five-minute stretch of each of your sessions.Intensely make use of the book as you go. Try to pick an interesting-looking stretch by first viewing the whole session once in TV fashion andtaking some notes.
5. When you proceed to develop your first own concepts, there is a bigdifference depending on your research interest. For some interests, oneor a few base concepts will lend themselves for an easy start. For exam-ple, if you are interested in knowledge transfer phenomena, you mightstart by annotating all explain_knowledge utterances and build islandsof annotations around them. For other research interests, this does notwork, because there are no obviously related base concepts to start from.For instance, if you are interested in pair members’ roles, you cannotpick out a few helpful base concepts that are obviously relevant. Rather,you would perhaps start annotating all phenomena with base conceptsuntil you detect interesting phenomena and start introducing your ownconcepts for them. There is no need to think about layers yet; you candecide this later.
6. If you find yourself modifying the base layer (rather than just adding toit) in places where this possibility is not mentioned in this book14, re-read Chapter 22, be honest with yourself, and make sure you are doingthe Right Thing. (Such modifications are dangerous, because they mayreduce the compatibility of base-layer-based studies which is a key ideaof our research approach.)
7. Now several things need to be done for which there is no obvious order.Do them all at once or find your own best ordering: Refine your ownconcepts; learn annotating base layer concepts and your own conceptsconcurrently in one go or in some efficient sequential fashion; find outwhich base layer concepts you do not need to annotate for your researchfocus (or at least not always).
14The possibilities that are mentioned in the book are marked by the pen symbol in the margin.
1.6. Terminology and notation 31
8. Move from open coding into axial coding and selective coding; do not for-get to write enough memos; formulate your theory. Write your researcharticle.
1.6 Terminology and notation
The goal for the base layer is to provide a set of abstractions that can be used toexplain15 what pair programmers say and do. We call each such abstractiona concept. If the concept is about saying, the piece of saying explained by theconcept is called an utterance, if it is about doing, the piece of doing explainedby the concept is called an activity. The act of applying a concept to explain anutterance or activity (by assigning the concept to the utterance or activity) iscalled annotation. All other terminology will be introduced as we go.
Much of the discussion in the book will make use of quotes taken from the rawdata used for our research. Such quotes are marked by quotation marks, color,font, and an icon in the margin as follows:
“OK, what did we want to do?”
Some of these quotes are offset from the text (as above) but most appear inline,like this: “The VirtualAttribute is here”. Program identifiers (such as theVirtualAttribute here) are typeset in non-proportional font.
The quotes are not verbatim: As the original recordings featured only Germanspeakers, the utterances have been re-composed in English in such a way as tobest reflect the illocution (see Section 2.3.2) and “feel” of the utterance and itsapparent real-time thought process, rather than the wording or normal Englishphrasing – the German phrasing was far from textbook German as well.
If a quote is fictitious rather than real, it is quoted and italicized, but appears inblack and without the icon, like this: “I never said this. Nobody did.”.
Many quotes not only contain words and standard punctuation marks but alsoother marks, using a very simple transcription system with only the followingmarkup elements:
• (...): Speaking pauseOne or more dots in parentheses. Each dot represents a pause of aboutone second.Example: “To go on here (.) I think it’s good to reflect for half an hour in yourhead how really (..) to go the way.”
15For “explaining” versus “describing”, see Section 1.4.4.
32 Chapter 1. Introduction
• (;;;): Speaking pause with other activityOne or more semicolons in parentheses. Each semicolon represents a
speech pause of about one second but meanwhile the speaker performssome manual activity (typically operating the keyboard or mouse).Example: “OK. (;;;;) That would be (!...!)”
• (~): An incomprehensible word
• (~~): Multiple incomprehensible words
• (~word): An almost incomprehensible (and hence unreliable) word
• <*information*>: Comment added by the transcriberThe content of triangle-star brackets is not spoken at all. These bracketscontain additional contextual information added by the researcher duringthe transcription to make the actual verbal content more intelligible.Example: “The VirtualAttribute is here in pro <*points on screen*>.”
• (quiet words): Quiet speakingA word or words in parentheses are spoken very quietly, more to oneselfthan to the partner.Example: “The get (..) (missing)”
• <**replacement**>: Replacement of a proper nounA name appearing in the quote has been taken out and replaced bya generic term in triangle-doublestar brackets in order to protect theanonymity of a person or company.Example: “The thing is, <**Developer**> and I yesterday discussed that wechange the FeatureProxySet.”
• (!...!): breaking offA bang-tripledot-bang in parentheses means the utterance ends prema-turely; the speaker breaks off or trails off in mid-sentence for no observ-able reason in particular.Example: “Really great would be, if we could return something that always(!...!) (..) hm (...) Wait-a-sec that always (!...!)”
• (!!...!!): getting interruptedA bangbang-tripledot-bangbang in parentheses means the utterance endsprematurely because the partner starts speaking, thus interrupting theprevious speaker. What the partner actually says may be quoted subse-quently, paraphrased in subsequent discussion, or ignored entirely.Example: “They could send every minute or every ten (!!...!!)”
• (!!subutterance!!): both partners speaking at onceThe partner begins to speak (and the utterance is shown in a separatequotation) while the speaker continues to speak (and the respective part
1.6. Terminology and notation 33
of the utterance is shown with the markup in the present quotation).Example: “Um, then you can easily, then you can easily change it. (!!That hadconfused me.!!)”
When annotating concepts to quotations, it sometimes becomes necessary toannotate more than one. There are two notations for this. Where two concepts,A and B, are annotated, A + B means “A applies to some part of the utteranceand B applies to some other part (but we still consider it a single utterance)”. Incontrast, A/B means “both concepts apply at once to an ambiguous utteranceas a whole”. In Example 8.2 (2), both of these notations appear at once:
C5.explain_knowledge + C5.amend_strategy/C5.disagree_stepmeans one part of the utterance contains an explain_knowledge and another parthas aspects of both an amend_strategy and a disagree_step.
The real-world phenomena explained by the concepts described here are fartoo complex to provide complete instructions for classification. You will oftenget to a point where our instructions end and you need to make up your mindyourself. Insofar as we are aware of these spots, the most interesting cases willbe marked with the “Think!” symbol shown on the side of this paragraph. Therespective page numbers are collected in the index under “Think!”.
Finally, paragraphs that discuss potential modifications of the base layer orextensions to it are marked with the pen symbol (like at the present paragraph).The respective page numbers are collected in the index under “base layermodification”.
Outside of quotations, italics are used to discriminate X from an utteranceregarding X. The later are what most concepts refer to and what will be typesetin italics; see the discussion in Section 2.3.5.
Chapter 2Overview of the base layer
2.1 What are the base concepts?
As mentioned previously in Section 1.6, the base concepts explain what pairprogrammers say and do on the level of individual utterances and individualactivities. As explained in Section 1.4.3, the base concepts are intended as afoundation for a variety of subsequent studies of pair programming. To do that,the base concepts remain neutral: they are not geared towards any particularresearch question and attempt to be as generic and flexible as possible.
The base concepts are designed to form a coherent whole: the base conceptset. Most of this book (Chapters 4 through 20) defines the base concept set byexplaining the base concepts grouped into topical blocks. We cannot provide acomplete and exact definition of any concept, because our concepts representcomplex, real-world phenomena. Rather, we will provide a multitude ofexplanations that each aim at distinguishing some cases of instances from non-instances of a concept. In particular, we sometimes provide what we call theprimary characterizing attributes of a concept. These are characteristics that areby construction necessary to be able to identify all instances of a concept; seefor example the typology of strategy utterances in Section 9.1.
It is important to understand that the base concept set does not aim to be acoding scheme. A coding scheme would attempt to define each code (concept)in such a way that it can be identified as mechanically as possible in order tomaximize inter-rater agreement. The idea of a coding scheme is incompatiblewith Grounded Theory Methodology. In contrast, the base concepts will be de-fined in a manner that attempts to maximize the reader’s capability of thinkingflexibly about what it is that appears to be going on in the pair programmingsession and what might be an appropriate manner of conceptualizing it. Wewill frequently encourage you to modify a base concept if it does not appear to
35
36 Chapter 2. Overview of the base layer
be able to express the phenomena of interest to your research well.
2.1.1 Concepts and concept classes
The concepts (with very minor exceptions) have structured names consistingof a verb and an object, such as propose_design, propose_step, agree_step. We callthe set of concepts that share a common object a concept class.
This structure makes it reasonably easy to remember and use correctly theconcepts although their overall number is not small: There are more than 70of them. This idea (and the individual verbs and objects) will be explained inmore detail in Chapter 3.
2.1.2 HHI concepts vs. HCI/HEI concepts vs. supplementaryconcepts
The structuring of the base concept set does not stop at concept classes. Abovethem, there are larger groups of concepts we call concept categories. Theprimary concept category, forming the heart of this book, is the HHI concepts,for “human-human interaction concepts”. They conceptualize saying: theverbal dialog between the pair members. The HHI concepts (part II of thebook) consist of 13 concept classes (explained in Chapters 4 to 17) and twoextra concepts (Chapter 18).
The secondary concept category are the HCI/HEI concepts, for “human-computer interaction and human-environment interaction concepts”. Theyconceptualize doing: interaction of a pair member with the computer or withthe rest of the environment (other than the partner and the computer). Theseconcepts are far less important for the base concept set and hence much lessdetailed and refined. The strange two-part name HCI/HEI stems from the factthat these concepts do not discriminate between e.g. reading off the screenversus reading off paper or between pointing to the screen versus pointing to aposter on the wall. The HCI/HEI concepts are explained in Chapter 19. Thereis only one chapter because the notion of concept classes fully applies to theHHI concepts only: All HCI/HEI concepts share the same pseudo-object sth(for “something”) and some other concepts use that pseudo-object, too.
Beyond these two concept categories there are only a few “supplementaryconcepts” explained in Chapter 20. Together with the HCI/HEI concepts, theyform the rather short part III of the book.
2.1.3 HHI concept class groupings
There is an intermediate level of grouping in between the concept classes andthe HHI category as follows:
2.2. What is the base layer? 37
1. Product-oriented concepts (2 concept classes) concern proposals (andtheir discussion) regarding the content, structure, and placement of theprogram artifacts, ranging from requirements and architectural designdown to individual identifiers and operators.
2. Process-oriented concepts (5 concept classes) concern proposals (andtheir discussion) regarding the work process. Furthermore, we will callthe union of product-oriented and process-oriented concepts the “P&P”concepts.
3. Universal concepts (6 concept classes) concern utterances that request,transfer, or judge knowledge, state the level of available knowledge,or formulate or judge an assumption or hypothesis. They are calleduniversal because they apply to the product context as well as the processcontext. The “Facade concepts” (1 concept class) are a subset of theuniversal concepts and provide a simplified view for (currently only onetype of) complex phenomena. They provide a context in which a complexphenomenon can be split up and its parts be described by other concepts,whether base concepts or higher ones. Currently, the only facade conceptsconcern the verbalization or evaluation of HCI/HEI activities.
4. Miscellaneous concepts (2 concepts) mark utterances that are unintelli-gible or have nothing to do with the pair programming task at hand.
2.2 What is the base layer?
The base layer is the union of the base concept set plus guidelines for its use.These guidelines are spread throughout the book and then supplemented andsummarized in the final part IV of the book. Part IV consists of
• a summary (in Chapter 21) of the annotation procedure rules scatteredthroughout parts II and III;
• guidelines for adapting the base concepts to the needs of a specific subse-quent study (Chapter 22);
• preliminary guidelines for creating your own concept layers (Chapter 23).
2.3 Key decisions for the base layer
The base concepts would look very different had we not made the fundamentaldecisions given below. For understanding the base concepts and for applyingthem correctly, it is helpful to keep these decisions in mind.
38 Chapter 2. Overview of the base layer
2.3.1 Primarily rely on verbalization
One possible attitude when analyzing pair programming sessions via GTMwould be “Pair programmers do many different things. One of these things istalking. But what counts is the code produced, so I am more interested in whatthey type into the computer.”
However, we quickly found that the talking contains far more interestinginformation than all of the other information channels and so decided to modelthe talking in much greater detail than the rest. This is reflected in the HHIpart of the base concept set being far larger than the rest, both in terms of thenumber of concepts and the level of detail in their description.
2.3.2 Model illocutionary acts
Our second insight was that one must not take the talking at face value butrather probe for its actual semantics in the pair’s dialog. For instance, whena speaker asks a question, this is often neither intended nor understood as arequest for information. Rather, it often is a proposal to do something specific –and that is just how the partner will react: with various forms of agreement ordisagreement. To be useful, the base concepts should model such an utteranceas a proposal, not as a question.
To put it a little more formally: Most of the HHI concepts designate whatthe speech act theory1 of Searle2 and Austin3 calls the illocutionary act of theutterance. The illocutionary act is the action that is performed by making theutterance. For ask this would be asking a question, for propose it would be makinga proposal even though the verbal and even the grammatical form may suggestsomething different. For instance, some pair programmers may formulate mostof their proposals as questions.
The researcher needs to make an effort to identify the actual illocution of anutterance rather than sticking too closely to the explicit formulation. Oftenthe intonation provides a good hint. If it does not, recognizing the illocutionis often difficult for an utterance in isolation, but is usually clear once oneconsiders other utterances from the session context before (and perhaps evenafter) the given utterance. Do not worry: The many examples provided alongwith the detailed discussion of the concepts below will make this process veryclear over time.
Assuming sane speakers, the illocutionary act basically is the speaker’s primaryintention. This raises two problems. First, is there always exactly one primary
1http://en.wikipedia.org/w/index.php?title=Speech_act&oldid=5668940062http://en.wikipedia.org/w/index.php?title=John_R._Searle&oldid=5671713443http://en.wikipedia.org/w/index.php?title=J._L._Austin&oldid=567339888
2.3. Key decisions for the base layer 39
intention? (And what does “primary” mean anyway?) Second, speech act the-ory knows hundreds of different illocutionary acts. How can this be compatiblewith our need for a modestly-sized base concept set?
Neither question has a short, neat answer and the detailed answers to bothproblems cannot be given here; they are spread over the discussions of theindividual HHI concept classes in chapters 4 to 17. Chapter 21 will provide asummary.
2.3.3 Let segmentation emerge
For some qualitative research methods that annotate raw data with concepts, itis very important to segment the raw data in a canonical manner, and elaboraterules are often needed to provide that manner. For our purposes, this isunimportant: Early on, our work found that the utterance is usually (there areoccasional exceptions) the right level of granularity for defining and applyingHHI concepts; we do not even need to determine sharp boundaries for each andevery utterance. (For the segmentation of non-HHI activities, see Chapter 19.)
But what is an utterance? Our seemingly paradoxical answer is: An utteranceis that which is neither too small to be explained by one concept nor so largethat the application of one concept no longer suffices to explain it.
This circular definition works well in practice because the researcher bringsin sufficient common sense knowledge of communication and its units ofmeaning. From this starting point, the HHI concepts can be developed fromutterances and the notion of utterance can be derived from the granularity ofthe HHI concepts. Much like the notion of illocutionary act above, this ideamay look mysterious, but we assure you that you will find it perfectly naturalonce you have finished working through this book.
This principle applies to our derivation of the base concepts as well as your useof them. It may have to be changed when progressing towards studies usingqualitative data analysis for quantitative purposes, e.g. comparing settingsregarding the frequency of certain events.
2.3.4 Crave for behavioristic interpretation
Determining the illocution of an utterance invariably involves some interpre-tation. Our fourth insight was that such interpretation can become a slipperyslope: There is constant danger of making assumptions that are unwarrantedand hence lose the grounding of the annotations made.
Behaviorism4 is a psychological school of thought that assumes the mechanismsof behavior can be adequately modeled by referring to observable stimuli and
4http://en.wikipedia.org/w/index.php?title=Behaviorism&oldid=568442418
40 Chapter 2. Overview of the base layer
observable responses alone, without referring to internal processes (“thinking”).Methodologically, behaviorism implies to abstain from the interpretation ofobservations as much as possible. Behaviorism has helped psychology to focusmore on falsifiable statements and get on a proper scientific track.
To escape the slippery slope of losing grounding in pair programming research,a behavioristic style of observation and description is a helpful ideal for theresearcher. The base concepts were created by applying that ideal to the extentthat appeared reasonable: Unfortunately, utterances are far too ambiguousto determine their illocution in a purely behavioristic fashion without anyinterpretation and assumption, but a behavioristic ideal creates a useful limitto the kind of concepts one is still willing to introduce.
As a result, we think the base concepts, while usually requiring interpretationwhen annotating (not rarely involving substantial uncertainty), almost alwayscreate annotations that a large majority of researchers will be able to agree onas acceptable. Note that “acceptable” is a far lower degree of agreement than“objectively correct”, the latter being impossible in this domain. Behavioristicinterpretation (a contradiction in terms!) is an ideal, not a goal.
2.3.5 Model the discourse world, not the activity world
The exact meaning of a base concept can be confusing until you realize thedifference between a thing X and an utterance about X.
For instance the base concepts use the term step for referring to atomic units ofwork (in a sense that will be explained in Chapter 6). But the step object thatforms base concepts such as propose_step or disagree_step does not refer to a step,it always refers to an utterance about a step.
This was our fifth insight: In contrast to the HCI/HEI concepts, HHI baseconcepts never5 refer to an element of the activity world (a deed), they alwaysrefer to an element of the discourse world (an utterance). Correspondingactivities may exist (at that time or some other) or not exist.
The book uses non-italicized words (such as step) to refer to the activity worldand italicized ones (such as step) to refer to the discourse world. Some of theexplanations are only intelligible when paying attention to this difference.
2.3.6 Model dialog episodes
It would be helpful if an encoding using the base concepts provided valuebeyond individual utterances and suggested a segmentation of the session intoepisodes. The objects of the base concepts do exactly that. An object (for examplestrategy) represents an individual topic (a particular strategy X) brought up
5Exception: The statement does not hold for the activity concepts.
2.3. Key decisions for the base layer 41
in the session. The various verbs represent the lifecycle of the topic: It startswith an initiative verb (Section 3.5) such as propose (perhaps preceded by aquery: ask), goes through any number of evaluations (agree, disagree, decide)and modifications (challenge, amend), and either ends with an evaluation, withswitching from talking to action, or is superseded by some other topic forthe time being – note that the same speaker may speak several times in arow, perhaps with pauses, in this process. The annotations will hence directlyrepresent (some) relationships between the utterances.
This effect is convenient, but you should be aware of its limitations:
• The particular topic is not a fixed object (such as strategy X), but ismodified during the discussion (as in Example 9.3), sometimes beyondrecognition.
• These *_strategy annotations may be interspersed with others, in particu-lar using universal concepts.
• Also, the HHI concepts, except for the activity concepts, do not indicate ifan utterance relates to the result of an HCI/HEI activity. For instance, anutterance may relate to a stretch of code that has been highlighted usingthe mouse. Relationships are less obvious in such cases.
• The episode marking is implicit and can hence be ambiguous. In particu-lar, an utterance may relate to more than one topic and several episodesmay mix.
When annotating base concepts to data, making and keeping relationshipsvisible is one of the criteria for the concepts to choose. However, the highestpriority is always given to intersubjective validity: Your choices need to beexplainable and agreeable. Note that the above notion of episode is useful forunderstanding and applying the base concepts, but once you start your ownpair programming research you will need to introduce a notion of episode thatis suitable for your particular research question.
2.3.7 Design the concepts to reflect relevant phenomena
The above decisions in no way make the choice of concepts canonical. Thereare many possibilities left how to structure the domain: The base concept set isnot the inevitable result of natural science, it is a construction. In our decisionshow to construct it, we have followed our best judgment (and the preliminaryinsights that arose during our analysis) in order to create concepts that reflectinteresting and relevant phenomena.
If and where the results do not fit your particular research topic, you can andshould modify them appropriately.
Part II
The HHI concepts:Human/human interaction
. . . in which we define the concepts that aim at verbal interaction. You havereached the heart of the book and are going to be pumped through its arteriesnow; hold on.
43
Chapter 3Objects and verbsof the HHI concepts
3.1 The structure and meaning of concept names
As mentioned in Section 2.1.1, the base concept set uses structured conceptnames. For the HHI concepts and the HCI/HEI concepts alike, each conceptname consists of a verb and an object, joined by an underscore. Examples ofHHI concept names would be explain_knowledge or propose_step. Some of theobjects are not words but phrases, as in explain_standard of knowledge.
As the same verbs and objects tend to occur in multiple concepts, this chapterprovides a simple explanation of each verb and each object as a first approxi-mation of the HHI concepts. Be aware that many of the concepts and discrim-inations between concepts are subtle (that is why we need a whole book toexplain them), so this approximation will be coarse.
Each object induces a concept class: the set of all concepts involving this object(precisely: all concepts whose name contains the object. Still more precisely:whose name contains the name of the object. However, while the differencebetween a concept name and the actual concept is a major topic of this book,we can and will afford to largely identify the name of an object with the objectitself, likewise for the verbs.). We will structure most of our discussion of theconcepts along these object-based concept classes (object classes).
We will sometimes (but not often) use the name of an object to refer to the objectitself and sometimes (and more commonly) to refer to the concept class inducedby the object. For example, knowledge may occasionally refer to a certain kindof knowledge (which we will carefully define and delineate later in the book)but will more frequently refer to the set of concepts explain_knowledge, agree_knowledge, disagree_knowledge, challenge_knowledge, ask_knowledge. Remember,
45
46 Chapter 3. Objects and verbs of the HHI concepts
however, that concepts describe utterances (Section 2.3.5). The third use ofknowledge is therefore to explicitly or implicitly refer to knowledge utterances –and thus to instances of a concept rather than a concept class. Likewise for allother HHI concept classes.
This third use is because, by virtue of being a concept, each object is a classitself: The class of all instances of that object. For example, when using theconcept propose_step to annotate a particular utterance found in a particular pairprogramming session, step will refer to an utterance about one particular stepbeing proposed out of an infinite number of conceivable steps being proposedor executed in any pair programming anywhere. When a concept is used in thismanner, we call it a code. In this book, most mentions of concept names refer tothe concept, not to a code. The primary exception are the illustrative examples;all full-blown examples (pair programming episodes) are highlighted.
Each verb induces a verb concept class as well, but we will not make much useof those.
If you are confused by these explanations, do not worry: if you pay attention tothe difference between the discourse world and the activity world as introducedin Section 2.3.5, things will become clear over time.
3.2 The objects
Our analysis for HHI concepts found 16 objects:
activity: An HCI or HEI activity that is currently ongoing.
completion: The degree of completeness of working through a particular workstep. See also step and state.
design: A possibility or choice for the content of the artifact(s) being workedon. May pertain to individual elements (such as the name of a method) or tohigher-level structure.
finding: An insight that was achieved shortly before (and then verbalized) byone pair member. Indicates the extension of knowledge based on cognitiveprocesses. See also knowledge and standard of knowledge.
gap in knowledge: A lack of a particular piece of knowledge in both pair members.See also standard of knowledge.
hypothesis: A hypothesis or conjecture, often regarding properties of the artifactsbeing worked on.
knowledge: Explicit knowledge that is neither meta-knowledge of the gap inknowledge or standard of knowledge types nor newly won knowledge of the findingtype, nor a hypothesis, nor is knowledge packaged as a suggestion regarding
3.3. The verbs 47
the work product or work process. Whether true or not, the speaker assumes itto be true.
off topic: Anything that has nothing to do with the task or its solution.
requirement: A given or assumed requirement or constraint for the solution tobe produced.
something/sth: An unspecifiable object. For HHI concepts, this is used onlywith the verb mumble.
standard of knowledge: How much one pair member knows with respect to acertain topic, except where this is a gap of knowledge (of both participants).
state: The degree to which a strategy has been worked through. See also strategyand completion.
step: A potential next step in the work process that the speaker considers to bean atomic unit of tactical behavior. See also strategy.
strategy: A somewhat longer-term (explicit or implicit) work plan for solving a(sub)problem that has not yet been fully worked through. Strategies typicallycover multiple steps. See also step.
todo: A subtask or step that is to be performed not now but rather at somespecified or unspecified later time during the same or a future programmingsession.
All of these only refer to entities a pair member has verbalized, if perhapsrather implicitly.
3.3 The verbs
Our analysis for HHI concepts found 13 verbs:
amend: Extending, complementing, or detailing either a previous utterance(HHI, typically propose) or a currently performed activity (HCI/HEI). Thismostly expresses agreement, not disagreement.
ask: Asking a question; typically an open one, sometimes a closed one.
agree: Expressing consent with either a previous utterance (HHI, typicallypropose) or with a currently or just previously performed activity (HCI/HEI).agree does not include explanations; if explanations occur, they are covered byan additional explain concept. See also decide.
challenge: Expressing dissent with either a previous utterance (HHI, typicallypropose) or with a currently or just previously performed activity (HCI/HEI)and (or by) making a counter-proposal. See also disagree.
48 Chapter 3. Objects and verbs of the HHI concepts
decide: Selecting one from among a number of possibilities (typically presentedby the partner in form of a propose). See also agree.
disagree: Expressing dissent with either a previous utterance (HHI, typicallypropose) or with a currently or just previously performed activity (HCI/HEI)without making a counter-proposal. See also challenge.
explain: Explaining something to the partner. Can occur as a reaction (to e.g. anopen or closed question from the partner, see also ask) or without an observabletrigger.
mumble: Making an utterance that is so fragmentary or phonetically so unclearas to be uninterpretable. Will only be used with the object sth.
propose: Making a proposal that does not refer to a recent other proposal. Theproposal may consist of one possibility or several (as a choice). The partner canreact with agree (in case of one possibility), decide (in case of several possibilities),challenge, disagree, or amend.
remember: Reminding oneself and the partner of something specific.
say: Saying something. Will only be used with the object off topic.
stop: Proposing to terminate a particular HCI/HEI activity.
think aloud: Verbalizing one’s own current activity or its related considerations.
3.4 The existing object/verb combinations
Overall, there are 60 HHI concepts, so by far not all of the 208 combinations of13 verbs with 16 objects do occur. This has a number of reasons:
• Some combinations simply make no sense.
• Some combinations make sense and can occur in practice, but are suf-ficiently rare that we never encountered them in our data. Since all ofthe concepts explained in this book are fully grounded in data to makesure they are valid, such unseen concepts are missing in our conceptset. As discussed in Section 22.4, you can and should introduce them assoon as you encounter instances of them in your own data and need therespective concept for your particular analysis.
• Some combinations make sense, but would overlap in meaning withsome other concept. To make coding canonical we have thus ruled outone of them. For example, there is no explain_step concept, because thebase layer defines that all explicit knowledge transfer is to be representedby means of the knowledge concept class.
3.5. Types of verbs 49
• There are two broad auxiliary concepts (mumble_sth (mumble something)and say_off topic) of low importance for which it was defined that theirverbs must not be combined with anything else.
Most of the time most of the verbs designate the illocutionary act (Section 2.3.2).
Figures 3.1 and 3.2 summarize all HHI concepts, grouped into concept classesand the larger concept class groupings. The subsequent chapters (pages 59to 178) will work through the individual HHI concept classes object by objectin a roughly uniform structure.
3.5 Types of verbs
The HHI concepts have three different types of verbs:
Initiative verbs introduce a new aspect into the discourse. Usually, no directreference (whether explicit or implicit) is made to the content of previousutterances. Initiative utterances do thus not have the character of a reply,although they may still address a topic previously discussed. The base conceptsprovide three initiative verbs: propose, remember, and stop.
Reactive verbs: Utterances that directly (whether explicitly or implicitly) refer toone or more previous utterances.
The verbs agree, amend, challenge, decide, and disagree can be used as reactiveverbs (but also to comment on activities).
Bivalent verbs: The verbs explain, think aloud, and ask can be used in an initiativefashion as well as a reactive fashion. For instance, a pair member may attempta knowledge transfer either based on a previous question of the partner oron any other trigger (observable or not), but both cases are conceptualized asexplain.
The verbs mumble and say carry only little meaning and are not classified.
There is a second verb classification besides the above one:
Constructive verbs are those where the utterance constructively introduces addi-tional aspects into the discourse: amend, challenge, explain, propose, and remember.
Unconstructive verbs are those where the utterance only requests new aspects orinformation or judges such aspects or information. These are ask, agree, decide,and disagree.
For this second classification, think aloud and stop are ambiguous and hence notclassified.
We call all concepts containing a constructive verb constructive concepts, etc.This book will not make much use of these classifications but they may be
50 Chapter 3. Objects and verbs of the HHI concepts
process-oriented concepts
miscellaneous
product-oriented concepts
Ask for a concrete proposal regarding the next tactical work step.
ask_step
Ask for a concrete proposal regarding the structure and content of
the program.
ask_design
Select one from among several alternative proposals regarding the next tactical work step.
decide_step
Extend a given proposal regarding the next tactical work step without rejecting the proposal.
amend_step
Reject a given proposal regarding the next tactical work step without making
an alternative proposal.
disagree_step
Make one or several alternative proposals regarding the next tactical
work step.
propose_step
Signal agreement with a given proposal regarding the next tactical work
step.
agree_step
Reject a given proposal regarding the next tactical work step and make an alternative proposal instead.
challenge_step
Make one or several alternative proposals regarding the structure and content of the
program.
propose_design
Signal agreement with a given proposal regarding the structure and content
of the program.
agree_design
Select one from among several alternative proposals regarding the structure and content of
the program.
decide_design
Reject a given proposal regarding the structure and content of the program and make an alternative proposal
instead.
challenge_design
Reject a given proposal regarding the structure and content of the program without making
an alternative proposal.
disagree_design
Signal agreement with a statement regarding the degree to which the current strategy or work plan has been worked through.
agree_state
Make a statement regarding the degree of completion of the current
tactical work step.
explain_ completion
Signal agreement with a given proposal regarding the strategy or work plan.
agree_strategy
Propose one or several alternative strategies or
work plans.
propose_strategy
Select one from among several alternative proposed strategies or
work plans.
decide_strategy
Ask for a concrete proposal regarding the strategy or work plan to be chosen.
ask_strategy
Signal agreement with a statement regarding the degree of completion of the current tactical work
step.
agree_completion
Remind the pair of a given (pre-specified) functional or non-functional require-
ment of the program.
remember_ requirement
Make an incomprehensible utterance (highly fragmentary or acustically unclear).
mumble_sth
Extend a proposed strategy or work plan
without rejecting it.
amend_strategy
Make a statement regarding the degree to which the current strategy or work plan has been
worked through.
explain_state
Extend a given proposal regarding the structure and content of the program without rejecting the proposal.
amend_design
Reject a statement regarding the degree of completion of the current tactical work step and make an alternative
statement.
challenge_ completion
Make an utterance that has nothing to do with solving the programming task.
say_off topic
Reject a given or proposed requirement and propose an alternative
one instead.
challenge_ requirement
Signal agreement with a given or proposed
requirement.
agree_ requirement
Propose one or several alternative program char-acteristics that should be considered to be a
requirement.
propose_ requirement
Suggest that a certain work item will need to be taken care of later in the process.
propose_todo
Signal agreement with a statement saying that a certain work item will need to be taken care of later in the process.
agree_todo
Reject a given proposal regarding the strategy or work plan and make an alternative proposal
instead.
challenge_strategy
Reject a statement regarding the degree to which the current strategy or work plan has been worked through and make
an alternative statement.
challenge_state
Reject a given proposal regarding the strategy or work plan without making
an alternative proposal.
disagree_strategy
Figure 3.1: The HHI concepts, part 1: P&P concepts (i.e., produce-oriented andprocess-oriented concepts) and auxiliary concepts.
3.5. Types of verbs 51
universal concepts
Reject a given hypothesis or conjecture.
disagree_ hypothesis
Formulate a hypothesis or conjecture, e.g. regarding a property of the program, or the environment.
propose_ hypothesis
Signal agreement with a given hypothesis or conjecture.
agree_hypothesis
Reject a given hypothesis or conjecture and formulate an alternative one.
challenge_ hypothesis
Extend a given hypothesis or conjecture without rejecting it.
amend_hypothesis
Explain or recapitulate one’s own level of knowledge with respect to a certain topic.
explain_standard of knowledge
Ask the partner for his/her level of knowledge with respect to a certain topic.
ask_standard of knowledge
Verbalize that certain knowledge is not possessed by either member of the pair.
explain_gap in knowledge
Transfer information to the partner that is assumed to be correct declarative knowledge.
explain_knowledge
Signal agreement (i.e. judge as correct) knowledge stated by the partner.
agree_knowledge
Declare transfered know-ledge as fully, partially, or potentially wrong by opposing it with one's own knowledge.
challenge_ knowledge
Ask the partner for information of type 'declarative knowledge'.
ask_knowledge
Declare transfered know-ledge as fully, partially, or potentially wrong without explaining why.
disagree_ knowledge
Declare transfered finding as fully, partially, or potentially wrong without explaining why.
disagree_finding
Signal agreement with a verbalized insight or interpretation.
agree_finding
Extend a verbalized insight or interpretation without rejecting it.
amend_finding
Verbalize a new insight; this includes interpreting an observed event.
explain_finding
Reject the content of a verbalized insight or interpretation and suggest an alternative one.
challenge_finding
Signal agreement with a given gap in knowledge.
agree_gap in knowledge
facad
e c
on
cep
ts
Verbalize aspects of one’s own current HCI or HEI activity.
think aloud_ activity
Propose an extension to the current HCI or HEI activity.
amend_activity
Reject all or part of the current HCI or HEI activity.
disagree_activity
Reject all or part of the current HCI or HEI activity and suggest an alternative activity.
challenge_activity
Signal agreement with all or part of the current HCI or HEI activity.
agree_activity
Suggest to stop or abort the current HCI or HEI activity.
stop_activity
Figure 3.2: The HHI concepts, part 2: universal concepts, including the facadeconcepts.
52 Chapter 3. Objects and verbs of the HHI concepts
c
oncepts
activity
concepts
activ
ity
concepts activity
concepts activity
knowledge co-verbalized in proposals for shaping the program or development process or in the
evaluation of such proposals
knowledge verbalized in other utterances
exis
ting k
now
ledge
new
insig
hts
cre
ate
d
during a
PP s
essio
n
findingconcepts
sta
ndard
of know
ledge c
oncepts
gap in k
now
ledge c
oncepts
hypoth
esis
concepts
design, re
quirem
ent, s
tep, co
mple
tion,
stra
tegy, st
ate
and todo c
once
pts
knowledge concepts
Figure 3.3: The landscape of knowledge-related utterances
helpful for use during higher-level analyses. You may then want to classify afew cases differently; for instance, questions (ask) can sometimes be consideredconstructive too.
3.6 The notion of “knowledge”
Most of this book is concerned with separating one concept from other similarones. A few of these separations are particularly important or particularlydifficult and we will therefore summarize some of this information upfrontin this and the following three subsections. This provides the first pieces ofunderstanding of base concepts that connect concept classes to one another.
Knowledge transfer is a key aspect of pair programming. In the base concepts,it is represented via the concept classes knowledge, finding, and standard ofknowledge, but also as an aspect of several (in fact almost all) other conceptclasses. The following discussion illuminates some aspects of how the baseconcepts handle the various subtle problems that knowledge and knowledgetransfer create during the analysis of pair programming. Use Figure 3.3 forguidance.
The notion of “knowledge” in the base concept set: Grounded Theory Method-ology requires to ground all concepts and statements in data, that is, in concrete
3.6. The notion of “knowledge” 53
observations. We therefore quickly decided we need to follow a behavioris-tic approach in our analysis: Rely only on what is directly observable andavoid modeling internal cognitive processes as best you can. For the notion ofknowledge this means we can represent only that knowledge that its ownercommunicates1 and where we observe this communication. In the followingplease note the discrimination between “knowledge” in general and “knowledge”in the narrower sense used in the base concepts. (Later on we will often moreloosely write knowledge where in fact we mean knowledge if precision is notimportant.) These considerations lead to the following definition of knowledge:
• The knowledge concept covers only explicit knowledge (that its ownercan consciously access and use), not tacit knowledge, and it covers onlyknowledge that is communicated, rather than only possessed.
• The communication of knowledge can be explicit or implicit. The explicitcommunication of knowledge can be verbal, this is the typical case, orwholly or partially nonverbal by sketches, gestures, etc. The implicitcommunication of knowledge happens by doing something and can occurunconsciously. knowledge is only explicitly communicated knowledge, notimplicitly communicated knowledge. This restriction makes the currentknowledge concept much more reliable, but may be too restrictive for somefuture analyses and should perhaps be lifted then.
• Knowledge is something the owner considers to be true, but it does notneed to be actually true. This restriction is necessary because the re-searcher is very often not able to verify the owner’s belief. This restrictedview of knowledge as belief also gets rid of many of the epistemologicalproblems that the notion of knowledge otherwise holds.
• These first three clauses define the necessary conditions for seeing aninstance of knowledge. The sufficient conditions are much more com-plicated, mostly (but not only) because most of the non-knowledge HHIconcepts concern objects that fall under the above three-clause definitionof knowledge as well, but the base layer defines that in those cases theknowledge concept should not also be used. For instance, when a pairmember explains a certain design pattern as such, this will be annotatedas explain_knowledge. If this explanation occurs as part of a suggestionhow to structure the program, it will be encoded as propose_design instead,not mentioning the knowledge aspect separately at all. This business issubtle: When the design pattern explanation is not part of the proposal,but rather a justification for it, the total utterance will be split and the
1More precisely: the owner communicates (in some form of expression) information that aimsto represent the knowledge and that may or may not turn into knowledge again at the receiver’sside. We ignore these transformations in the terminology of our book, which will be difficultenough without this additional complication.
54 Chapter 3. Objects and verbs of the HHI concepts
parts annotated as propose_design and as explain_knowledge. Many moresuch distinctions are required. It is due to such distinctions that we needa whole book to explain the base layer and in most cases we will state thereasons for making them.
• Various things need to be subtracted from the definition of knowledge thusobtained. They will be discussed below.
The above definition of knowledge is almost synonymous to knowledge transfer,so we will often use this more explicit latter term. Transfer here stands forpotential transfer, not necessarily successful or actual transfer, and in principleit indicates only the fact of potential transfer, not necessarily the intentionof transfer. Furthermore, we will sometimes speak of information instead ofknowledge.
Separation of some forms of meta-knowledge: The base concepts discrimi-nate between a certain form of knowledge about knowledge (meta-knowledge)and other forms of explicit knowledge: The class standard of knowledge repre-sents assessments one pair member makes about his or her own gradual levelof knowledge (or lack thereof) with respect to a certain fact or topic.
Partial separation of existing knowledge vs. new knowledge: Quite obvi-ously, things the pair finds out during a session are of particular relevancewhen analyzing the pair programming process. The base concepts hence dis-criminate knowledge that has been possessed by one or both of the partnersfor some time (existing knowledge) from knowledge that just a moment agosprang into existence (new knowledge: insights). The latter is represented bythe object class finding. Not all finding concepts represent verbalizations ofinsights, though. For instance, an utterance annotated with amend_finding maycontain only existing knowledge, but it pertains to a finding.
All knowledge the partners presumably already possessed before the session isconsidered existing knowledge, but findings become existing knowledge forlater parts of the session as well.
Partial separation of certain knowledge vs. uncertain knowledge: The classesknowledge or finding are used if the speaker is subjectively certain of his or herknowledge. If s/he reveals s/he is not, hypothesis is used instead, no matterwhether the knowledge is new or existing.
Separation of product or process proposals: Another aspect besides findingsthat is obviously key to understanding the pair programming process is pro-posals (pertaining to the composition of the artifacts being worked on or to thesteps and strategies of the development process itself) as well as the evaluationsof such proposals.
Most of the proposals and many of the evaluations contain and transmit knowl-edge but this is not annotated separately. So even an obviously knowledgeful
3.6. The notion of “knowledge” 55
product-related proposal will only be annotated with propose_design and notwith an additional explain_knowledge. However, if the proposal is subsequentlyjustified, typically by explaining its rationale, that utterance will by annotatedseparately and as explain_knowledge (or perhaps explain_finding):
Example 3.1: An episode from session BA1 (14:08:27–14:09:00) contain-ing a design proposal complemented by a rationale based on a find-ing. The pair is working on an if statement that will stop the script ifone of a number of conditions is met. The pair had previously markedsome of the conditions as needing change (“TODO”).
(1) B2.ask_knowledge
“What happens if this one is not set?”
The question refers to a script parameter.
(2) B1.explain_knowledge
“That makes the script continue at least as long as we (.), er, (.) do notmake the ’Change’ at each spot – write the Memcache. (...)”
The driver answers the question immediately. We have no indicators thatlet us assume a finding, the answer comes from existing knowledge. Afterhis reply, he pauses for three seconds.
(3) B1.explain_finding
“Although if we don’t write it to the Memcache, he’ll return it anyway,some time.”The combination of pausing and “although” suggests this was not existingknowledge.
(4) B1.propose_design
“We can leave that up there for now. (..)”
Based on his insight, the driver now makes a proposal: Let us not changethe marked conditions or at least not yet.
(5) B1.ask_standard of knowledge + B1.explain_finding
“Know_what_I_mean? If we now only change this script here (.) then itwould only (.) this would never become true. So we would never returnexit('NOCHANGE') and just continue here – and that would be just thesame functionality.”
After a short pause, B1 justifies his proposal by explaining his insight againin different words. He points to various spots in the code while doing so.
56 Chapter 3. Objects and verbs of the HHI concepts
Such separate annotation is used likewise for process-related proposals such aspropose_step or propose_strategy, their status-evaluation cousins explain_comple-tion/explain_state (where finding will be more typical than knowledge), and soon.
3.7 propose vs. explain
The same idea of discriminating objects concerned with a few important spe-cialized types of knowledge from more general ones recurs for the verbs. Forthe objects, all proposals (and comments on such proposals) that concern thecontent of artifacts or the shaping of the development process are encoded byconcepts from the design, requirement, step, strategy, or todo classes even if (asthey usually do) they include knowledge transfer, while “pure” knowledgetransfer (and comments about its content) is encoded primarily by knowledgeand finding concepts.
This discrimination is reflected in the use of the verbs propose versus explain.For instance, there is a concept propose_design, but no concept explain_design.Explanations around a design are either explanations of the design as such(these are encoded as propose_design, no matter how detailed) or justifications,explanations of the design’s rationale. The latter are considered “pure” knowl-edge transfer and are thus encoded as explain_knowledge. Note that in practiceit is often quite difficult to separate a proposal from its justification, becausethe proposals are often rather implicit; see Example 4.1.
Somewhat in between those two cases is the hypothesis class: It clearly belongsinto the “pure” knowledge transfer, but is still used with the verb propose (notwith explain), because in real sessions hypotheses are (at first) typically onlystated, not elaborated.
3.8 explain vs. think aloud
What is the difference between the seemingly similar verbs explain and thinkaloud? The latter is used only in the rather peculiar concept think aloud_activitywhich serves to bracket whole sequences of utterances describing the content,meaning, or purpose of HCI/HEI activities of the speaker that occur at roughlythe same time.
In contrast to all other concepts, for which it is expected that only one conceptwill usually be annotated to any one utterance (see Section 2.3.3 for a discussionof segmenting speech into utterances), activity concepts are defined such thatany of their utterances can be annotated with additional concepts, includingexplain_knowledge, as needed. If you find this confusing or extravagant: It willbe explained in Chapter 17.
3.9. disagree+propose vs. challenge 57
3.9 disagree+propose vs. challenge
A challenge is basically a disagree combined with a propose (for P&P concepts)or with an explain (for universal concepts), so why do we introduce a wholeadditional verb concept class for this case?
There are two reasons: First, the fact that disagreeing and proposing are com-bined in a single step is important and would be lost when using separateconcepts. Second, propose has been classified as an initiative verb, but challengeclearly is and must be reactive.
Chapter 4Product-oriented concepts: design
4.1 Topic of design concepts
design concepts concern proposals (and their discussion) regarding the content,structure, and placement of the program artifacts in the broadest sense, insofaras they can be decided upon by the pair. These artifacts are typically execution-related ones such as program code or configuration files (and our observationscovered only those), but could be other types as well. This definition includesdifferent aspects ranging from architectural design down to individual identi-fiers and operators, and touches issues on various levels of granularity such asthe expression level, statement or variable declaration level, control constructlevel, method level, class level, or package level.
Here are a number of examples:
Example 4.1: Separate examples of design phenomena from SessionsZB7, BA1, and CA2. The explanations show how utterances can oftenbe interpreted only using context information such as previous utter-ances (Example (c)) or recent computer outputs (Example (e)).
(a) ZB7: Z20.propose_design
“A TopicConnection we need.”
Z20 is editing a newly created method clone. The original method sentan object via a JMS Queue, the clone is to be changed such that it uses aJMS Topic instead. Z20 is suggesting to change a declaration from typeQueueConnection to TopicConnection.
(b) BA1: B1.propose_design
“And how we call the thing? id?”
59
60 Chapter 4. Product-oriented concepts: design
B1 is driver and suggests a name for a variable. The initial question is notannotated as ask_design, because B1 answers it himself immediately and alsostarts typing right away.
(c) BA1: B2.agree_design
“Ummmmm.”Agreement to a previous proposal (in fact the one right above).
(d) BA1: B2.propose_design
“What do we return? Shall we (!...!) (.) getFriendsLastChange. Wewant a timestamp, right? Or true or false?”
Observer B2 makes alternative proposals for possible return values. Heframes the two choices as questions, but the initial question is rhetoricalonly: An answer follows right away. It is therefore not separately anno-tated as ask_design.
(e) CA2: C2.propose_design
“Yeah, that needs to go.”
C2 is driver and refers to a method call he intends to remove that is cur-rently highlighted in the editor.
(f) CA2: C5.propose_design
“We need to use the FeatureProxy to retrieve the values.”
C5 is observer. He suggests an approach for accessing required data.
Excluded from the design concept class are decisions fixed (at least conceptually)before the pair programming session; those are modeled by requirements con-cepts as defined in Chapter 5. Also excluded is the detection of the unavoidableneed for corrections due to programming errors as discussed in Section 12.1.2.
4.2 design concepts and their properties
As shown in Figure 3.1, we have observed ask_design, propose_design, agree_design, decide_design, disagree_design, amend_design, and challenge_design.
The following subsections explain how to recognize corresponding phenomena.Example 4.2 provides a complete design discussion episode.
Example 4.2: A design discussion episode from Session CA2 (12:55:47–12:56:49). The observer C5 suggests to refactor the constructor of classDisplayNameFeatureProxyTableModel.
4.2. design concepts and their properties 61
(1) C5.propose_step
“I would (.), let us look at the TableModel, how that works, how thatfetches the values.”
Before C5 finishes this utterance, C2 has opened the source file in the edi-tor.
(2) C5.propose_design
“Well (.) I (.) think (.) that TableModel shouldn’t know—mustn’t know—that it’s using virtual columns or non-virtual columns.”
C5 says this after a pause of 5 seconds during which C2 has not changedthe view, which primarily shows the constructor. During this utterance, C2starts scrolling downwards.
(3) C2.agree_design
“Okayyyyyy.”
C2 agrees half-heartedly.
(4) C2.explain_standard of knowledge
“That’s the abstraction I’d thought of before.”
The context shows that C2 had apparently thought about this problembefore the session. While speaking, he scrolls back to the constructor.
(5) C2.mumble_sth
“Have you ’n principle, haven’t you ’n principle (!...!)”
Fragment, unclear. May be a cut-off agreement.
(6) C5.amend_design
“That should (...), that should get itself a ValueProvider from the configu-ration.”C5 adds an implementation detail to the proposal, referring to the construc-tor’s parameter attributeConfiguration.
(7) C2.agree_design
“You’re not wrong there, essentially.”
C2 more or less agrees.
(8) C2.explain_standard of knowledge
“Yes, that’s the abstraction I’d thought of before.”
62 Chapter 4. Product-oriented concepts: design
(see above)
(9) C2.mumble_sth
“That means (...) OK. (!...!)”
Fragment, unclear.
(10) C5.amend_design
“that you, that we extend the attribute configuration by such aValueProvider and that will give it the Feature (.), that will give itthe the the that that that FeatureProxy to fetch the values (.) and the resthappens after that.”
After a two-second pause, C5 continues the sentence of C2 and substanti-ates his design proposal.
4.2.1 Types and intentions of proposals
Most design discussion episodes start with a propose_design, just as it is shortlydescribed (for strategy) in Section 2.3.6. As you can see in Example 4.1, proposalsare not often explicit. More commonly, and as explained in Section 3.7, noproposing verb is provided and only the content of the proposal is spelled out –often as an assertion (see (a) in Example 4.1). Another popular form is that of aquestion (see (b) in Example 4.1). Both forms can be combined by appendingthe question to the statement (e.g. “OK?”).
Whether the speaker considers the utterance to be a proposal or rather a case ofcourteously informing the partner of final decisions (if the speaker is observerthis means: giving instructions) can often be decided only by relying heavilyon the session context or not at all. When giving information or instructions,the speaker would neither expect nor desire a verbal reaction. For instance,driver-speakers often start typing right away (see (b) in Example 4.1) or evenduring their utterance.
The base concepts ignore this difference in intentions and encode both casesand all their variations as propose_design (and likewise for amend_design andchallenge_design), so that the concept addresses a broad variety of utterancesthat can be summarized as follows.
Required and optional elements of propose_design utterances: A propose_design can transport three types of information:
i. A design aspect
ii. The speaker’s positive evaluation of this aspect
iii. A request to the partner to evaluate the aspect
4.2. design concepts and their properties 63
Only the first of these is required, which leads to three plausible modes ofpropose_design utterances:
• Mode OE (utterance provides i+ii+iii): Obtain evaluation. Example fromCA2: “Well, I would, overall I would make this so that the FeatureProxySet(.) uses those TableModel properties (.) Yah.” This is a refactoring proposal.At its end, the speaker turns to his partner and looks at him – only thisestablishes the OE mode.
• Type PI (i+ii): Provide information. Example from CA2: “You mustoverwrite it.” The observer instructs the driver C5 to overwrite a certaininherited method. The driver, however, does not do that. Instead, hesuggests to have a look at the superclass first.
• Type LO (i+iii): Look for orientation. Example from BA1: “The question is:Should we return anything at all?” See Example 4.3 for discussion.
We have seen all of these three modes in our data but not the unlikely fourthin which the proposal would serve no purpose at all. The modes are oftendifficult to tell apart; in particular, the evaluation request tends to be implicitand gradual. They are nevertheless helpful as a mental model.
propose_design and indirect speech acts: The above three modes of speakerintention cannot usually be determined based on the syntactical form of theutterance of the terms used in it. For instance, an utterance in the form of aquestion may well be a proposal and can even be a PI-mode proposal. Searlespeaks of indirect speech acts1: An illocutionary act of asking a question isinvolved, but it is only the secondary illocution. The actual primary illocutionis making a proposal and the utterance is hence called an indirect speech act.The base concepts ignore the secondary act in such cases and represent theprimary one only.
As mentioned above, all of these considerations also apply accordingly foramend_design and challenge_design. Very similar ones apply to other conceptclasses involving proposals, most notably step and strategy (propose_step, amend_step, challenge_step, propose_strategy, amend_strategy, challenge_strategy).
4.2.2 Referring to editing steps
We said above that propose_design always transports a design aspect (informa-tion type i). Note that this transport needs not happen verbally.
Here are two non-verbal examples:
1http://en.wikipedia.org/w/index.php?title=Speech_act&oldid=566894006#
Indirect_speech_acts
64 Chapter 4. Product-oriented concepts: design
• In Session CA2, C2 modifies a method and during that process utters “Itought to have been implemented like this.”. This constitutes a propose_designin mode PI.
• In Session CA2, C5 executes an IDE wizard for creating a new Javapackage, enters the package name, and before clicking “Finish” asks“Correct?”. This constitutes a propose_design in mode OE.
4.2.3 Proposals with rationale
A propose_design is often accompanied by a justification: an explanation ofthe proposal’s rationale. Such explanations should be annotated separatelyas explain_knowledge or explain_finding. The same holds for justifications thataccompany instances of challenge_design, amend_design, or disagree_design.
For instance, the observer in BA1 refuses a design proposal by saying “Butthat’s horrible. Then we have two loops; that’s crap.” The first sentence should beannotated as disagree_design, the second as explain_knowledge. We will revisitthis rule in Section 16.1 about the knowledge concepts.
4.2.4 decide vs. agree
Using decide_design requires that at least two different design options havebeen proposed previously. Then, decide_design is an explicit choice of one asopposed to the other(s) – in contrast to a mere agree_design with respect tothe last-mentioned variant. decide_design works much like propose_design: Ifthe partner subsequently prefers a different choice, this will be annotated aschallenge_design, not as another decide_design.
We will see such an episode (regarding strategy) in Example 9.3.
4.2.5 amend vs. a new propose
We use amend_design if the speaker makes a previous proposal more concrete byadding detail or an extension. It is often difficult for the researcher to discrimi-nate such amendments from entirely new proposals, because the reference tothe original proposal is almost always purely implicit.
4.2.6 amend or challenge one’s own proposal
It is quite common to find amend_design (see Example 4.2) or challenge_designutterances not only with respect to proposals coming from the partner, but alsoas self-corrections of the speaker’s own previous proposals. This statementmay be true for all types of amend and challenge concepts in the base conceptset, although we have not actually observed it in all concept classes. We willrevisit this in Section 21.6.5.
4.2. design concepts and their properties 65
4.2.7 Indicating agreement vs. indicating attentiveness
Many of the utterances that could be affirmative are quite short: “OK.”, “Right.”,“Yea.”, “Yes.”, “Hmm.”, and so on. This makes it often hard for the researcher todecide whether this is affirmation of content (and hence agree_design) or ratherwhat linguists call backchannel2 communication: A mere indication of atten-tiveness and interest, without content-related meaning. That same ambiguityexists for the listening partner, and the speaker is expected to know this, so thebase layer considers all potentially affirmative backchannel utterances to meanagree. This holds accordingly for all agree verb classes in the base layer.
4.2.8 Short negations
Likewise, short utterances that could be either rejection or backchannel (mostlya variety of grunting sounds) should be annotated as disagree. A particularlyproblematic example would be an appropriately pronounced “Hmm.”, becausethe intonation might be right in the middle between affirmation and rejection.This, too, holds accordingly for all agree verb classes in the base layer.
4.2.9 Proposal-less questions
We use ask_design when the speaker asks for how something ought to bedesigned without indicating any design idea of his or her own. This is incontrast to design proposals that are merely formulated as a question.
Example 4.3: Partial episode from Session BA1 (14:10:51–14:10:59) thatstarts with ask_design. The question starts a 1-minute episode duringall of which the pair discusses the return value of a PHP script that isto be called by an external service provider for retrieving informationfrom the system being developed here. The discussion is on the fringebetween design discussion and requirements discussion (see Chapter 5),but is classified as design because one can see (just not in the examplepart here) that the external provider has no voice in deciding the in-terface. In the part shown, B1’s question does not achieve its goal: B2does not make a proposal – so B1 cautiously formulates one himself.
(1) B1.ask_design
“What should be pass on to them really?”
(see caption) The question addresses only the return value for one particu-lar if case.
(2) B1.explain_finding
2http://en.wikipedia.org/w/index.php?title=Backchannel_(linguistics)&oldid=
565247022
66 Chapter 4. Product-oriented concepts: design
“NOCHANGE is surplus data here.”
B1 continues right away; B2 does not say anything. The script returns theNOCHANGE string, but as it is called frequently, this may be inefficient. Thisfinding justifies the previous question.
(3) B1.propose_design
“The question is: Should we return anything at all?”
Three seconds later, during which nothing happened, B1 suggests to maybenot return anything. This transforms his original question into an LO-modeproposal.
4.2.10 Restricted disagreement
Rejections of proposals may be formulated such that the speaker sounds fullycertain, perhaps uncertain, likely uncertain, or explicitly uncertain. For instance,in Session CA2 after the statement “This we could pull out there.” C2 reacts bysaying “(Hmm, yes.) (..) I’m not sure whether I (.) would pull it out there.” Theexample shows that even verbal agreement and disagreement can be hardto discriminate: The first part is grammatically affirmative, but the speakerutters it rather quietly. The second part explicitly expresses uncertainty buthas more rejecting character than affirming character and is uttered after someconsideration, so we annotate the whole as disagree_design – but clearly thedisagreement is far weaker than 100 percent. We will revisit this issue inSection 21.6.4.
4.3 Discrimination from similar concepts
4.3.1 propose_design vs. ask_knowledge
As discussed above, questions that ask for comments on a fresh(!) designpossibility are always annotated as propose_design, never as ask_knowledge: First,design aspects have been excluded from knowledge, so knowledge can neverapply. Second, we treat the question as an indirect speech act, that is, weignore the secondary illocution of asking and annotate the primary illocutionof proposing.
4.3.2 *_design vs. explain_knowledge/explain_finding
The general rule for design proposals and their discussion is: design takesannotation precedence over both knowledge and finding. Only justifications(if present) are annotated separately and then use either explain_knowledgeor explain_finding. (This holds likewise for justifications of other proposals,
4.3. Discrimination from similar concepts 67
most importantly step and strategy). However, the following corner cases needseparate discussion:
Packaged design proposals: Design proposals might be enclosed in a knowl-edge utterance, that is, formulated such that the knowledge transfer aspectappears to be the primary one. A double annotation using both the knowledgeand the design concept should then be used, because either of the two alonewould lose an important (rather than just a secondary) aspect of the utterance.See Example 17.2 in the discussion of the activity concepts.
Packaged agree/disagree for a design proposal: Likewise, agreements andrefusals can also be enclosed in a knowledge utterance and again a doubleannotation is appropriate in order not to misrepresent the utterance. SeeExample 16.2 (for a step proposal).
ask_design vs. ask_knowledge: Queries for obtaining a design proposal arenot design proposals, but are still covered by the precedence rule: Annotatethem specifically (as ask_design) not generically (as ask_knowledge).
There will be deeper discussion of these rules in the knowledge Chapter 16.
4.3.3 propose_design vs. propose_step/propose_todo
As we see, the discrimination of design concepts from explain_knowledge isnormally straightforward. The same is not true (sometimes) for discriminatingpropose_design from propose_step and from propose_todo. To understand thosedifferences, however, a detailed understanding of the latter’s concept classesis required, so we postpone the discussion until the respective Chapter 6 (forstep) and Chapter 8 (for todo).
Chapter 5Product-oriented concepts:requirement
5.1 Topic of requirement concepts
The requirement concepts talk about requirements imposed on the pair’s workresults from outside the session. Such requirements can be functional (includ-ing API requirements), non-functional (including constraints of any kind) andtheir key characteristic is that the pair cannot change them. In particular, designdiscussion must be annotated as requirement, if and insofar a certain design hasbeen imposed on the pair from outside.
However, requirements are not necessarily known and clear. There are fourmajor cases:
• Requirements known since before the session.
• Requirements recognized during the session, including those merelyassumed by the pair, often temporarily, during the session.
• Requirements recognized during the session to be missing.
As all our concepts, the notion of requirement was not predefined or taken froman external source, it was developed from phenomena in our data and is fullygrounded in them; see the examples below and subsequently.
Example 5.1: Some requirement utterances.
(a) BA1: B1.propose_requirement
“OK, let’s assume they have one hour difference.”
69
70 Chapter 5. Product-oriented concepts: requirement
A computation depends on time of day, but the pair does not knowwhether the clocks of the two servers in question will be properly syn-chronized. The utterance proposes a constraint that may help understandand tackle the problem.
(b) CA2: C5.remember_requirement
“And the other thing I had understood that we try (.) to make this invisiblefor the other things by the Facade.”
Driver C5 refers to an agreement from (apparently) before the session.This agreement imposes the structural requirement that the module be-ing worked on here shall have a Facade structure. For the overall product,this is a design aspect; for this particular session, it is fixed a-priori and ishence a requirement.
(c) CA2: C5.remember_requirement
“The thing is, <**Developer**> and I yesterday discussed that we changethe FeatureProxySet. It shall have a getTableModel.”
C5 refers to an agreement how to change the present class. He intends toapply this agreement in many of the subsequent steps.
5.2 requirement concepts and their properties
As shown in Figure 3.1, we have observed remember_requirement, propose_requirement, agree_requirement, and challenge_requirement.
The following subsections explain how to recognize corresponding phenomena.Example 5.2 provides a short requirement discussion episode.
Example 5.2: Discussion of a missing constraint requirement from Ses-sion BA1 (16:25:18–16:25:34). Starting point is the pair’s new findingthat the script they are developing will only be able to return the cor-rect results if the clock on the caller’s system (outside the pair’s control)is synchronized with the clock on the local system.
(1) B1.propose_requirement
“Ideally, they could simply send a timestamp of now. (...)”
To solve the problem, B1 suggests a requirement that should be imposed onthe caller.
(2) B1.challenge_requirement
5.2. requirement concepts and their properties 71
“But they cannot send a timestamp each time so we can look ’hey is yourclock off?’. They could send every minute or every ten (!!...!!)”
After three seconds of actionless pause, B1 changes his own proposal. Hestops in mid-sentence because B2 starts speaking.
(3) B2.challenge_requirement
“They could send a keepalive.”
B2 makes a counter-proposal, to which B1 reacts without any delay:
(4) B1.agree_requirement
“That’s an idea.”B1 agrees to that third proposal.
5.2.1 remember_requirement
The speaker recapitulates a requirement, typically because he or she has justbecome aware (or aware again) that it exists or that it is relevant, sometimesto remind the partner of it or consciously bring up the topic. This is the onlyconcept that uses the verb remember, because this case of what could otherwisehave been covered by explain_knowledge is special in that the knowledge repre-sents a condition that has arbitrarily been imposed on the pair and overlookingit will unavoidably produce problems (whereas other knowledge can often besubstituted).
5.2.2 propose_requirement
What superficially looks like remember_requirement may in fact talk about re-quirements that nobody has yet imposed but that the pair finds necessary inorder to proceed. The subsequent discussion of a propose_requirement is moresimilar to propose_design than it is to remember_requirement, because the pair hasfreedom to make their own (suitable) decision rather than merely interpret andhandle something given; see Example 5.2.
Sometimes, these “requirements” are temporary assumptions that serve toreduce complexity and aid thinking; see (a) in Example 5.1. As such, they areprovisional and may later be fixed, changed, or may disappear entirely.
5.2.3 agree_requirement and challenge_requirement
These two concepts can occur in the context of a propose_requirement as well asof a remember_requirement, but their character is different in either case. In the
72 Chapter 5. Product-oriented concepts: requirement
propose case, they talk about how to use a degree of freedom, in the remembercase, they talk about the truth of facts.
disagree_requirement and amend_requirement could naturally occur as well, butwe have not seen them in our data.
5.3 Discrimination from similar concepts
All relevant considerations have already been explained:
• Use remember_requirement where externally imposed constraints are con-cerned and propose_design where the pair’s leeway in decision-makingis concerned. This could have been (even should have been) externallyimposed, but was not; so the pair makes up its mind itself.
• Conceptually, remember_requirement is a specialization of explain_knowl-edge. Where the former applies, use it, but do not use the latter. SeeChapter 16 for details.
• Conceptually, propose_requirement is a specialization of explain_finding.Where the former applies, use it, but do not use the latter. See Chapter 12for details.
Chapter 6Process-oriented concepts: step
In contrast to the product-oriented concept classes design and requirement dis-cussed in the previous chapters, the process-oriented concepts talk about howthe pair steers its development process (mainly within this particular pairprogramming session). There are five concept classes that cover three topicareas:
• Utterances regarding tactical behavior, i.e., regarding short-term acts per-formed currently or in the immediate past or future. These are addressedby the step and completion concept classes that will be discussed in thepresent chapter and in Chapter 7, respectively.
• Utterances regarding somewhat longer-term, strategic behavior. Theseare addressed by the strategy and state concept classes that will be dis-cussed in Chapter 9 and Chapter 10, respectively.
• Utterances regarding deferring work steps or subtasks in order to performthem at some later time. These are addressed by the todo concept classthat will be discussed in Chapter 8.
The terms tactical, strategic, short-term and longer-term are vague; lengthyexplanations will be required to make them well-defined. The key to tellingthem apart will be the notion of strategy. The explanation, however, worksbetter if we start with step.
6.1 Topic of step concepts
When analyzing pair programming sessions, it quickly becomes obvious thata large fraction of the utterances has to do with deciding the next work step.
73
74 Chapter 6. Process-oriented concepts: step
This is what the step concept class talks about. By next work step we referto activities that can be started right away rather than needing substantialpreparation. By work step we only refer to process issues, because productissues are already covered by the design (or possibly requirement) concept class.(And as for design, the concepts only address the work step proposal itself;justifications for it will be annotated as explain_knowledge or explain_finding.)
By work step (as opposed to some larger unit) we refer to atomic units of work.But what is atomic? Is, for instance, closing a window atomic? Or do you needto go down to the electron-level events in the nervous system that result incontracting a muscle which results in clicking a mouse button which results inclosing the window? We found that neither of these is sufficiently relevant tobecome a base concept – nor is the outcome of any other “objective” definitionof atomicness.
It turns out the only useful definition is: A step is atomic if a pair memberconsiders it atomic. More precisely: If s/he talks about it in a way that representsthe step as atomic (behavioristic perspective) – so that the researcher concludesthat s/he considers it atomic1. In this subjective view of atomicness, thedefining characteristic is not that the work step cannot be divided at all, butrather the speaker currently views it such that it needs not be divided in orderto be decided and begun. Once the actual execution of the step has started, thestep may turn into something non-atomic that requires further discussion of itsinnards.
But outside its execution, a step in this sense is a single means to a particularend and a step utterance does not place it in the context of further actions. Theend may be mentioned or (more often) not.
In practice, step utterances can refer to simple activities such as executing acertain well-understood command on the computer (“Do a ’save’.”) or to morecomplex ones such as performing a manual test (“We could make an a first testnow.”), discussing an interface to be created, understanding some existing code(“I would (..) let us have a look at TableModel how that works how it fetches thevalues.”), or implementing a particular method.
Note that work steps to be performed later rather than now are represented bytodo rather than step, and work stretches considered non-atomic during theirdiscussion are represented by strategy rather than step.
Example 6.1: Utterances annotated with step concepts and referring tosimple actions (such as (d)) or complex activities (such as (b)). Exam-ples (c) and perhaps (a) show cases where a reply is not expected, theutterance has purely informational character.
1This conclusion could be wrong if the talking misrepresented the thinking for some reasonbut we have never found any evidence that this was happening in our sessions.
6.2. step concepts and their properties 75
(a) BA1: B1.explain_finding + B1.amend_step
“Errrr, (.) yes, complete nonsense of course; we can search in our WorkingSet.”The pair is searching for calls of a particular function. B1 had started asearch of the whole workspace and now finds it will take long. He pro-poses a more restricted search and starts it.
(b) CA2: C5.propose_step
“Then (.) (it is so) I’ll first show you what I’ve done.”
The pair will have to work on code sections worked on by C5 before thesession. C5 suggests to bring C2 up-to-date.
(c) CA2: C5.propose_step
“(OK. Refactor.)”
C5 has proposed to move a class to a different package. He now scrollsthrough the Eclipse IDE’s package explorer, finds the class, opens the con-text menu on it, and makes the utterance. Less than a second later he startsthe refactoring from the context menu.
(d) CA2: C5.propose_step
“Properties.”
The pair is testing the application. The driver hesitates and the observersteps in with a proposal where to click next.
(e) CA2: C5.propose_step
“Also change the TODOs above into NOWs.”
The driver is just tagging a new, empty method as TODO_NOW. The ob-server suggests to do the same for the class’ other empty methods, cur-rently tagged TODO.
6.2 step concepts and their properties
As shown in Figure 3.1, we have observed propose_step, agree_step, decide_step,disagree_step, challenge_step, amend_step, and ask_step.
6.2.1 propose_step with rationale
A proposal can be complemented by a justification giving its rationale. Just likefor propose_design, such explanations should be annotated separately, either
76 Chapter 6. Process-oriented concepts: step
with explain_knowledge or explain_finding as appropriate.
For instance, after the amend_step utterance from Example 6.1, the speakeradded
I thought I had anyway checked out the <*Working Set*> only, but (!...!).
This justifies why he changes his former proposal: His previous assumptionthat workspace and working set are the same was wrong (explain_finding).
In principle, all other step utterances could also come with a rationale, but wehave seen only few instances of that. We will revisit the discrimination betweenexplain_knowledge and propose_step in Section 16.3.1.
6.2.2 Purpose of making propose_step utterances
By far not all propose_step utterances appear to constitute requests for com-ments. In particular when made by the driver during HCI activities, propose_step is often merely information about what the speaker intends to do next;Example 6.1 (c) is a good illustration of this type.
Some propose_step utterances quite explicitly call for a reaction from the partner,for instance “Perhaps you could quickly have a look at it?” or “We can close it, right?”,but in (for example) Session CA2 only 12% of the propose_step utterances clearlyhad such character.
Overall, the same proposal types apply to step than we had explained for designin Section 4.2.1. Example 6.2 contains a step utterance in LO mode.
Example 6.2: An LO-mode propose_step utterance from Session CA2(12:58:08–12:58:16). The driver had previously made a design proposalthat amounted to doing a refactoring and apparently the pair had nodoubts that this was appropriate at least in principle. Whether to actu-ally do it (or what else if not), still needed to be decided, however.
(1) C2.propose_step
“The question is whether I dare do it now, whether we dare do it now.”
The observer asks whether the pair should perform a proposed refactoringor not in so open a manner that he clearly wants a comment from thepartner and states no preference of his own. (The utterance is actually aborderline case in between step and strategy; see Section 9.3.3. The contextprovides too little evidence of strategy-ness, however.)
(2) C5.agree_step
“I would like to dare do it now.”
6.2. step concepts and their properties 77
The driver interprets the question as a proposal and agrees.
(3) C2.agree_step
“OK.”The observer agrees as well, effectively adding late a judgment of his for-mer proposal.
Just like for propose_design, if a proposal is phrased as a question, only theprimary illocutionary act will be considered in the annotation; see the discus-sion in Section 4.2.1. A proposal can also be made to contradict a finding as inExample 12.6 (2).
6.2.3 Reserving time
Sometimes the speaker does not actually mention the intended step, but onlyasks for the time needed to do it. A typical example is “Wait a second.” fromSession CA2. The step itself (such as reading or thinking) will then often bedone alone.
6.2.4 Imprecise proposals
Proposals can be incomplete, vague, or ambiguous. Even if the observer makesa request or gives an order, the proposal may leave the driver a lot of leeway;see Example 6.3.
Example 6.3: An amend_step episode from Session CA2 (12:18:25–12:18:31). Observer C2 makes a vague proposal more specific when herecognizes that his partner does not act as he had intended. The driverhad previously clicked the first ’error’ entry in the Eclipse IDE’s Prob-lems View. This had sent the pair to an editor view that showed severallines as containing defects. After a short pause, the observer makesthe proposal shown. The episode shows that we cannot always decidewhether an utterance is indeed an amend_step: We may either assumethe second utterance simply delivers additional precision and annotateit as amend_step, or assume the “maybe better” means the observer hasindeed changed his mind and annotate as challenge_step. We chose theformer, but not without writing a coding memo to make a note of theproblem.
(1) C2.propose_step
“Point the, point the mouse, please.”
78 Chapter 6. Process-oriented concepts: step
The observer asks the driver to hover the mouse over one of the defectsshown in the editor in order to display the tool tip that will contain theerror message. He does not say which defect, though. The driver choosesthe last defect shown and its message opens.
(2) C2.amend_step
“No, there; maybe better hover that one.”
After the pair has looked at the message for about a second, the observerpoints his finger to a different error icon and makes his former proposalmore specific.
6.2.5 decide_step vs. agree_step
See the discussion in Section 4.2.4. We have seen decide_step only once.
6.2.6 amend, challenge, or disagree one’s own proposal
As described for design in Section 4.2.6, it is not at all unusual if a speakersupplements his or her own proposal with further detail. This can even happenif the partner has not said anything in between to make sure the partner acts orunderstands as intended or to supply new thoughts formed in the meantime.
Continued thinking may also lead to challenging or even sometimes revoking(disagree_step, see Example 6.4) one’s own proposal. As Example 6.3 showsfor amend vs. challenge, it is not always easy to tell these cases apart. Similarphenomena should be expected in most other HHI concept classes as well.
Example 6.4: Episode from Session BA1 in which B2 takes back his ownstep proposal after he recognized that the step would not lead to thedesired result: The output is basically timestamps of certain databaseentries, but there is no reason yet why they would change. The episodeillustrates two things: First, findings need not be triggered by externalstimuli. Second, spontaneously changing one’s mind is often evidenceof a finding.
(1) B2.propose_step
“Let’s do a refresh again.”
The observer suggests to refresh the browser view, which would call thePHP script again that the pair is currently editing.
(2) B2.disagree_step + B2.explain_finding
“Ah, no, we haven’t done Set yet.”
6.3. Discrimination from similar concepts 79
After about one second, the observer takes back the suggestion and ex-plains why.
6.2.7 Indicating agreement vs. indicating attentiveness
See Section 4.2.7.
6.2.8 ask_step
Questions that ask for the next work step without proposing one are annotatedas ask_step. Such questions can be general or pertain to a particular context, andthey can be new or request recapitulation of something previously discussed.The question “What did we want to open?” from Session ZB7 that talks about thenext file to be analyzed is of the context-and-recapitulation type.
6.3 Discrimination from similar concepts
We will talk about discrimination of step concepts from knowledge conceptsand from design concepts only. Discrimination from todo concepts and strategyconcepts is postponed until those classes have been explained.
6.3.1 *_step vs. explain_knowledge/explain_finding
Proposals for the next work step can be interpreted as knowledge. The generalrule for step proposals and their discussion is: step takes annotation precedenceover both knowledge and finding. Only justifications (if present) are annotatedseparately and then use either explain_knowledge or explain_finding. (This holdslikewise for justifications of other proposals, most importantly design andstrategy). For additional discussion see Section 12.3.3.
6.3.2 propose_step vs. propose_design
Quite obviously, realizing any proposed design aspect requires certain worksteps at some point. Therefore, design proposals often go hand in hand withwork step proposals. Since in such contexts the design concept class is the morespecific one and double annotations are generally frowned upon in the baselayer, propose_design takes precedence and propose_step should then be avoidedas illustrated by Example 6.5. Note that design proposals are often formulatedin procedural wording and will then superficially look like step proposals; seeExample 6.6.
80 Chapter 6. Process-oriented concepts: step
Example 6.5: Episode from Session BA1 (14:51:32–14:51:43) thatillustrates both the difference and the interplay between pro-pose_design and propose_step. The pair wants to insert calls toupdateFriendsLastChangeTime in all relevant places in the code. Theyneither yet know where these places are nor whether they should previ-ously refactor.
(1) B2.propose_design
“And then also the region when we delete again.”
The driver has just completed calling updateFriendsLastChangeTime inmethod setFriendship. Now the observer suggests adding the same callinto several delete operations.
(2) B1.amend_design
“OK, then we can either attach ourselves to this Hook, (!!...!!)”
The driver makes the idea more concrete. While speaking, he scrolls tomethod deleteFriendsIDsFromMemcache which he deems one of those oper-ations.
(3) B2.propose_step
“Let’s see how that looks where the User is deleted.”The observer interrupts the driver’s utterance and suggests looking at themethod responsible for deleting a User. Whether this pertains to B1’s utter-ance at all or not we do not know.
(4) B1.challenge_step
“We could also first look for all the places this is used.”
B1 immediately dissents by making yet another proposal. While speaking,he points the cursor to method deleteFriendsIDsFromMemcache.
Steps 1 and 2 show how design proposals imply work steps. Step 3 shows howpropose_step may imply the refusal of a previous proposal (disagree), but sincesuch refusal can rarely be recognized unambiguously, the base layer suggestsnot to annotate it.
Example 6.6: A design proposal that directly leads to action from Ses-sion BA1 (13:53:56–13:54:08). No propose_step is used in such cases.
(1) B2.propose_design
“We could simply, er, convert that thing in a, in a normal id, I mean,code_to_id and then id_to_code again.”
6.3. Discrimination from similar concepts 81
The observer suggests how to modify a certain if-condition that tests prop-erties of an external call argument.
(2) B1.agree_design
“OK.”The driver agrees and immediately starts executing the proposal.
6.3.3 propose_step vs. ask_knowledge
Questions of type “Should we do X next?” or “Should we next do X or rather Y?”mention possible steps. They are therefore annotated with the more specializedpropose_step rather than the more general ask_knowledge (and with the closed-question verb propose rather than the open-question verb ask).
Although this sounds like a hard and fast rule, there are difficult cases:
Implicated action announcements: The question
“Do you know how the (.) how I access the function for changing amethod?”
(from Example 16.2) superficially asks for how to access a certain IDE function-ality and should be annotated with ask_knowledge. However, the question alsoimplies what the speaker intends to do next, which warrants a propose_step.Indeed the partner hears both of these aspects and answers “That doesn’t get youanywhere.” The base layer suggests to double-annotate such cases with bothask_knowledge and propose_step. More generally, questions for knowledge, inparticular procedural knowledge, may imply subsequent steps. Section 21.6.1will specify that such implications should be made explicit whenever they arerecognized.
Remind of a proposal by asking: Sometimes a formerly proposed (and per-haps discussed) step that was not executed is proposed again later. For variousreasons, this may take question form, for instance because the speaker is notsure of the exact proposal anymore:
“OK, we said delete and, umm, what else?”
Again, both aspects are strong enough here and so the base layer suggests toannotate such cases with both ask_knowledge and propose_step; see Section 21.6.3for details on handling repetitions.
82 Chapter 6. Process-oriented concepts: step
6.3.4 ask_step vs. ask_knowledge
Any open question specifically for a step will be annotated specifically withask_step, not generically with ask_knowledge.
6.3.5 ask_step vs. ask_design
For a question such as
“OK, what did we want to do?”
it will often be unclear (even when consulting the context) whether it aims atstep or at design. ask_step as the more general concept may then be more ap-propriate. Annotating both concepts may be appropriate to express ambiguitythat appears intended by the speaker.
6.3.6 disagree_step vs. explain_knowledge/explain_finding
The rejection of a proposed step needs not be explicit, it can be wrapped in aknowledge transfer as in the “That doesn’t get you anywhere” in Section 6.3.3above. Both aspects of this indirect speech act are relevant in the base layerperspective, so we annotate both the primary and the secondary illocutionaryact, although which one is primary may be different from case to case: theknowledge transfer (explain_knowledge or explain_finding) or the rejection ofthe proposal (disagree_step). The same consideration sometimes applies tochallenge_step as well.
6.3.7 amend_step vs. explain_knowledge/explain_finding
Just like for propose_step, we annotate a justification or rationale separately foramend_step if one is supplied and use either explain_knowledge or explain_findingas appropriate.
Chapter 7Process-oriented concepts:completion
Where the step concepts talk about an individual work step, the completionconcepts talk about whether (or to what degree) the step has been fully andadequately performed and completed or not.
The strategy and state concept classes form a corresponding pair for compoundwork.
7.1 Topic of completion concepts
A completion utterance refers (explicitly or implicitly) to a work step. It talksabout the evaluation of the degree or quality of fulfillment of the step’s execu-tion or of some intermediate stage of the step’s execution.
The step may have been addressed by a previous step dialog episode or (fre-quently) not.
Example 7.1: Utterances annotated with completion concepts, all fromvarious stages of Session BA1
(a) B1.explain_completion
“I still do not like this very much.”
83
84 Chapter 7. Process-oriented concepts: completion
The driver says this after 15 minutes of work that started with an amend_design about adding functionality to a certain method. To avoid side ef-fects, the pair had decided to check where and how that method was beingcalled, which had led to analyzing many spots in the code neither of thetwo were familiar with. The pair had suggested a number of modificationsbut performed only few of them. The explain_completion utterance evaluatesthe success with respect to a step that was never formulated explicitly.
(b) B1.explain_completion
“I’d say we now have the problem conceptually (.) narrowed down andsolved.”Uttered after a three-minute-long discussion that had never been proposedbut had started spontaneously after a propose_design.
(c) B1.explain_completion
“Well, that wasn’t so bad really.”
After modifying a number of phpDocumentor comments, the driver leansback in his chair and makes this utterance. The lean-back gesture under-lines the interpretation that the speaker considers the current work step,which had never been verbalized, done.
(d) B2.challenge_completion
“But we haven’t done anything yet!”
Answer to (c). The observer points out that the actual editing steps stillhave to be made. This is not disagree_completion because the speaker offershis own, alternative evaluation.
7.2 completion concepts and their properties
As shown in Figure 3.1, we have observed only explain_completion, agree_completion, and challenge_completion, but of course a researcher may add theremaining ones as soon as they are encountered.
Most of the discussion about these three verbs from the previous conceptclasses applies. We offer only three additional remarks.
7.2.1 Short evaluations
In contrast to the cases shown in Example 7.1, most explain_completion utter-ances we have seen were short and simple (often just “OK.”) in particular fromthe driver to announce the end of editing steps.
7.3. Discrimination from similar concepts 85
7.2.2 Indirect evaluations
An explain_completion can be indirect by stating that something needs not bedone.
An example is the “Well, no need to go up here any more” after four minutes ofwork in Session BA1.
7.2.3 Evaluation of quality
The base layer does not discriminate evaluations of the quality of a work resultfrom less differentiated statements; both are annotated simply with explain_completion. Separate elaboration may be annotated with explain_finding (orperhaps explain_knowledge), but higher concept layers may need to add muchmore differentiation.
7.3 Discrimination from similar concepts
completion applies to step in the same way that state applies to strategy. Theirdiscrimination is easy if the work type has previously been discussed, becausethen the decision in favor of either step or strategy has already been made. Forcompletion or state utterances of implicit steps and strategies, however, it can besubtle.
The distinction of a proposed evaluation (explain_completion) and its justifi-cation (which should then be annotated with explain_finding) is harder thanfor design or step because a completion proposal itself may have so little bodythat it becomes mostly implicit (as in Example 7.1 (c)); see the discussion inChapter 12.
Chapter 8Process-oriented concepts: todo
8.1 Topic of todo concepts
Like step, the concept class todo talks about individual work steps. While steptalks about the current or next step, todo utterances serve to make note of stepsthat at least one pair member intends to delay until either some indefinite timeor some time beyond the end of the current session.
Example 8.1: todo episode from Session CA2. No particular time forexecution nor a particular ordering of steps is scheduled.
(1) C5.explain_knowledge
“There’s a test for it.”
After the pair discussed changes to a class, C5 remarks that a correspond-ing test class exists; he opens the test package in the IDE’s package explorerto validate or illustrate this.
(2) C5.propose_todo
“We must remember, uh?”
Without break, he adds that the pair should not forget to adapt the testclass at some appropriate later time.
Example 8.2: Episode from Session CA2 (12:20:27–12:20:46) in which thepair agrees on a todo in the midst of a strategy discussion. Deferring thestep helps avoiding discussion complexity excess.
(1) C2.amend_strategy
87
88 Chapter 8. Process-oriented concepts: todo
“That means, I guess we should do that now, perhaps we should check infirst?”
C2 has just taken the driver role and extends the two-part strategy (see Sec-tion 9.1) he had just proposed by another step, to be done first: checking inthe code. While he speaks, he turns towards his partner.
(2) C5.explain_knowledge + C5.amend_strategy/C5.disagree_step
“Um, I would rather(!...!). There are few tests there and I would rather notcheck in (!!...!!).”
After a two-second pause, C5 points out there are few unit tests for thecode. His primary intention appears to be to refuse the check-in step, butsince he had agreed to the overall strategy beforehand, disagree_strategywould not be an appropriate interpretation; see Section 21.6.2.
(3) C2.propose_todo
“Then let’s write some tests.”C2 interrupts and proposes to write tests without saying when. The subse-quent events show that C2 does not mean this to be a step proposal.
(4) C5.agree_todo
“Yes, we should certainly do that too.”
C5 agrees but still specifies no time. The “too” sounds like “but not now”.
(5) C5.amend_strategy
“Er, rather not check in before I’ve tried the GUI.”
After his agreement, C5 completes his formerly interrupted statement. Onlynow we can see his original intention to do an amend_strategy by addingone step.
(6) C2.agree_strategy
“OK, then let’s try the GUI.”
C2 agrees and the pair next tests the GUI.
8.2 todo concepts and their properties
We have observed relatively few todo utterances. As shown in Figure 3.1, onlythe types propose_todo and agree_todo occurred, but of course a researcher mayadd the remaining ones as soon as they are encountered.
How we define todo phenomena so far is:
8.3. Discrimination from similar concepts 89
• The proposals were not very concrete and never specified a time.
• Some, however, may specify the conditions under which the step wouldbe needed; it would not be needed if those conditions never hold. Astraightforward case is Example 8.3. Although these utterances have astrong component of explain_knowledge or explain_finding, we interpretthem as propose_todo: “I propose we perform step X in case condition Cmaterializes.”
• Our todo phenomena all had the form of declarative sentences, such as“Need to mind that, too.”.
Example 8.3: Episode from Session CA2 (12:43:03–12:43:08) involving aconditional todo that points out the consequences of a pending decision.
(1) C2.decide_design
“I guess it mustn’t go into Abstract.”
Currently, class FeatureAttributeConfigurationProxy is a subclass ofAbstractFeatureConfiguration (which the speaker calls Abstract). Thepair discusses whether this should remain true and agrees the inheritancewould be appropriate only if the superclass had less functionality. C2 de-cides to go that way: remove some functionality from the superclass.
(2) C5.amend_design/propose_todo
“Well, OK, then we have to implement this in very many places.”
C5 agrees but points out laborious consequences: the functionality removedfrom the superclass will eventually have to be inserted into many existingsubclasses.
8.3 Discrimination from similar concepts
The discrimination of design, step, and strategy on the one hand (current plan-ning) versus todo on the other (markings for future planning) is likely importantfor the control of a pair programming session, so we should discriminate themcarefully. Since strategy is complex and has not yet been introduced, we post-pone its discussion until Chapter 9 and only discuss discrimination from designand step here.
8.3.1 propose_todo vs. propose_step
As said before, step talks about the next work step, todo talks about a workstep at some later time. However, pair programming dialog utterances convey
90 Chapter 8. Process-oriented concepts: todo
much of their information implicitly and so actual step and todo utterances maylook rather similar if they are purely claims of necessity.
These properties suggest a propose_step utterance:
• The utterance invites to action (“Let’s. . . ”) without specifiying a time.
• It uses terms such as “now” or otherwise indicates immediacy.
• It followed by the execution of a corresponding step.
These properties suggest a propose_todo utterance:
• The utterance uses future tense.
• It uses terms such as “later” or “eventually” or otherwise indicates deferral.
• It states a particular later time or condition when to perform the step.Statements of time are rare, because the speaker will rarely make theeffort of deciding a suitable time unless s/he is formulating a strategy. Soif a time is specified, always check whether you are seeing e.g. a propose_strategy (etc.) rather than a propose_todo.
• The purpose of the utterance appears to be to get rid of an objectionquickly, as in item 3 of Example 8.2 that appears to “protect” the speaker’soriginal suggestion to check-in the code by calming down the partner,even though that requires interrupting the partner in mid-sentence.
Even if these symptoms are missing or ambiguous, reliance on context infor-mation will normally allow to discriminate todo utterances reliably. Note theremark on double annotations with todo and design concepts below.
8.3.2 propose_todo vs. explain_knowledge/explain_finding
As discussed before in the context of design, step, and strategy, todo utteranceshave the character of explain_knowledge (or explain_finding) but take precedencewhen annotating, because todo, being more specialized, is more informative.The class exists because of its plausibly important role for how pair program-ming sessions usually work.
8.3.3 propose_todo vs. amend_design/propose_design
An amendment for a design proposal can be accompanied by, or even entirelyconsist of, a statement of future work the proposal entails. In both of thesecases you should annotate both concepts, propose_todo as well as amend_design,because both aspects are separately important for the session; see Example 8.3.
8.3. Discrimination from similar concepts 91
This idea will occasionally apply to other design concepts as well, in particularto propose_design.
Chapter 9Process-oriented concepts: strategy
Where the step concepts talk about an atomic work step, the strategy conceptstalk about planful compound work.
9.1 Topic and typology of strategy concepts
The strategy concepts address those parts of a dialog (or monolog) in which thepair attempts to plan, decide, or coordinate complex stretches of work withrespect to some higher-level goal (see Section 9.3.3). A strategy in this sense isan idea or approach for longer-term, planful action.
As all other concepts in the base layer, this notion of strategy (which we willexplain in a lot more detail below) was not taken from the extensive existingliterature on that term but rather fully extracted from our observations in pairprogramming sessions only. This extraction was a lengthy process duringmost of which ’strategy’ appeared to be a confusing and untidy concept. Theprocess became satisfactory only after we started to discriminate three types ofstrategies: OWP, DPR, and EXS.
9.1.1 OWP: Organizing Work Packages
The current task (or a part thereof) is divided into specific (and typically non-atomic) pieces, which we call subtasks. An OWP-type strategy usually specifiesor implies a certain work-sequence order of the subtasks.
9.1.2 DPR: Determining Procedure Rules
Rather than decomposing the task explicitly into an ordered set of more-or-less explicit subtasks, the pair speaks about rules or guidelines intended tohelp devise or execute subsequent work continually. These rules often aim at
93
94 Chapter 9. Process-oriented concepts: strategy
simplification, for instance by excluding certain types of work step (such aswriting tests) or by deciding to provisionally ignore particular complicationsfrom design consideration.
9.1.3 EXS: Expanding a step into a strategy
What was originally a step or design may be expanded, by the same speakeror the partner, into a strategy by adding an additional step to be performedand viewing both together in light of a higher-level goal. Often this takes theform of remarking that after the previous proposed action, only the additionalactivity X will be needed to reach the desirable state Y.
These types help a lot in identifying and understanding strategy utterances,but despite the coarseness of this classification it can be difficult to apply. Wetherefore add two additional properties of strategy utterances: The type ofrepresentation and range.
9.1.4 Extensional vs. intensional representation
A strategy can be verbalized in extensional manner, by mentioning actionsseparately and explicitly, or in intensional manner, by subsuming actions undera single abstraction that represents an action superconcept or a criterion.
Most commonly, OWP strategies and EXS strategies are extensional whileDPR strategies are intensional, but neither is mandatory. For instance, thefollowing utterance from Session ZB7 could be considered an intensionallyexpressed OWP strategy proposal: “Um, should we here, um, these instructions onexecuting, um, XPetstore, look it through and follow it?” Superficially, this looks liketwo steps: looking through instructions; following instructions. Semantically,however, the utterance suggests a longer sequence of steps (those given inthe instructions) without explicating them. The above example could also beconsidered a DPR strategy utterance and this holds for all intensional OWPproposals we have seen so far.
9.1.5 Range
A strategy can have a mid-term or long-term planning horizon. A long-termstrategy pertains to all of the rest of the current session or beyond. A mid-termstrategy pertains only to some shorter stretch of intended work. There is no suchthing as a short-term strategy. This would either be a step (that is, consideredatomic) or we would call it mid-term – even though its actual execution mighttake less time than a lengthy step. It is often hard to tell the range of DPRstrategies.
9.1. Topic and typology of strategy concepts 95
9.1.6 Mixed types
Note that these properties do not allow classification in all cases. A singlestrategy utterance may have extensional as well as intensional parts, there areambiguities between intensional OWP and DPR utterances, and the range maybe hard to determine, in particular for DPR utterances.
For the base layer, this is not a problem because the properties serve only tounderstand the nature of possible strategy utterances better. They are primarycharacterizing attributes. Future research, however, may want to address thesetopics. In that case, our considerations here may serve as a starting point or beignored. Here are some (mostly isolated) examples of strategy utterances.
Example 9.1: Examples of strategy utterances from all three sessions.
(a) ZB7: Z19.ask_strategy
“How do we start?”At the start of the session, Z19 asks this very open question, which soundsmore like propose_step than propose_strategy. But since the partner answerswith a strategy proposal, the utterance effectively turns into one of thisclass.
(b) ZB7: Z20.propose_strategy (OWP, long-term)
“I would ignore the EmailSpy for now. And modify the the XPetstoreonly.”
Reply to (a). Z20 proposes two steps and their order, which covers thewhole of the session.
(c) ZB7: Z20.propose_strategy (DPR, mid-term)
“Know what we do? We use our existing EmailSpy for debugging.”
The driver proposes a testing approach that involves using a class the pairhad developed in a previous session for a different purpose but that will behelpful for detecting possible failures.
(d) CA2: C5.propose_strategy (DPR, mid-term)
“And I won’t much adapt any old tests from any old people.”
The driver formulates a radical avoidance strategy for coping with multiplesubtasks he deems too difficult and/or too large, namely to not solve anyof them at all.
(e) BA1: B1.propose_strategy (EXS, mid-term)
96 Chapter 9. Process-oriented concepts: strategy
“And then we only need to insert this thing in all spots where (friendschange).”
B1 extends a step proposed by his partner by another step and implies thetwo together will reach a substantial goal, which makes it a propose_strategy.
9.2 strategy concepts and their properties
As shown in Figure 3.1, we have observed propose_strategy, agree_strategy,decide_strategy, disagree_strategy, challenge_strategy, amend_strategy, and ask_strategy.
9.2.1 Proposal mode
Besides the properties explained in the previous section, the proposal modesintroduced for step in Section 4.2.1 apply to strategy as well and awarenessof the modes may help identify strategy utterances correctly. For instance,proposals (b) to (e) from Example 9.1 all have mode PI. Keep in mind that theactual formulations may be rather indirect. We have not yet observed a propose_strategy in mode OE.
9.2.2 Proposals with alternatives
As all propose phenomena, strategy proposals may specify several alternatives.Take this example from Session CA2: “Then we should do that before or after. Butnot at the same time.” This talks about when to perform certain restructurings inthe code. It formulates two alternative possibilities and excludes a third; seeExample 9.3 for its context.
9.2.3 decide_strategy vs. agree_strategy
The same discussion applies as in Section 4.2.4.
9.2.4 Secondary issues
A propose_strategy may include aspects not directly related to solving the taskat hand, e.g. related to session breaks (for whatever reason).
Example 9.2: Episode from Session CA2 (12:58:55–12:59:38) in which astrategy is discussed for a number of dialog steps.
(1) C5.explain_knowledge + C5.propose_strategy
“But our (.) stand-up starts in two minutes anyway. And when we go tolunch then. That means we have time to think it (~~).”
9.2. strategy concepts and their properties 97
C5 remarks on a constraint and then rudimentarily formulates a strategy.“it” is the content of the pair’s previous discussion.
(2) C2.explain_standard of knowledge
“You want to have lunch right after the stand-up and stop this, stop thisnow?”C2 interrupts C5 to validate his understanding.
(3) C5.propose_strategy
“I want to have lunch right after the stand-up.”
C5 interrupts C2 (and finishes before him!) to repeat and clarify a part ofhis previous proposal. Section 9.3.2 will explain why this is not a propose_todo. Section 21.6.3 will explain how to handle repetitions.
(4) C5.amend_strategy
“No, I want to continue after lunch (~would) with this work task.”
Right after C2 finishes, C5 details his proposal. (The pair then discusses aminor matter we skip here.)
(5) C2.agree_strategy
“OK, I would have liked I guess (.) to continue a bit. But OK.”
C2 reluctantly acquiesces to the proposal.
(6) C5.explain_state
“As for checking in and so on, I think we are at a point where we can take abreak.”C5 explains where he sees the work with respect to the goal. This is morean assessment than a proposal.
(7) C5.agree_state
“Of course, that’s true.”
This utterance agrees to the proposal as much as to the assessment.
9.2.5 Forms of amend_strategy
An amend_strategy utterance adds detail to an existing proposal either by addingone or more steps to a proposal (typically of type OWP, such as in Example 8.2(1)) or by making existing steps (for types OWS and EXS) or rules (for typeDPR) more concrete or more detailed.
98 Chapter 9. Process-oriented concepts: strategy
An example for the latter occurred shortly after the episode of Example 9.2. C5elaborates his lunch proposal by saying
“To go on here (.) I think it’s good to reflect for half an hour in your headhow really (..) to go the way. Or should we better take your cautiousapproach?”
9.2.6 Distinguishing proposals: amend, challenge, propose
Utterances in discussions of extensional OWP strategies often refer to individ-ual pieces of the strategy only, rather than the whole. This makes it hard todiscriminate amend from challenge from propose. The following heuristics mayhelp:
• If the speaker signals to basically agree with the strategy and only addsor details individual pieces or aspects, use amend_strategy.
• If the speaker refuses important pieces of the strategy and replaces theseconstructively, use challenge_strategy. Without replacement, this amountsto refusing the strategy overall and one should annotate disagree_strategy.
• If the speaker singles out one piece and elaborates it (often by turning itinto multiple smaller pieces) while ignoring the remaining pieces, thereare two possibilities: If the elaborated piece appears to replace all of theprevious strategy, this is challenge_strategy. If the remaining pieces appearto keep their previous role, it is amend_strategy.
In practice, however, it may be hard to decide whether pieces are really ignoredor merely not mentioned, and there may be neither symptoms of agreementnor symptoms of disagreement.
An instance of this problem is Example 8.2 which is preceded by a two-stepOWP proposal: 1. add method, 2. review dialog. C2 suggests another step tobe done first (check in) and the remainder discusses whether yet another step(try GUI) should be added still before that. In the end, however, it is unclearwhether the original steps are still part of what would by now be a four-pieceplan (1. try GUI, 2. check in, 3. add method, 4. review dialog) or only the newsteps remain (1. try GUI, 2. check in). If the first strategy is fully executed, itcan be considered intact, but it may never come to that, for many reasons.
The base layer cannot solve this problem, but its concepts help to notice suchphenomena and provide a starting point for researching their meaning andrelevance.
9.3. Discrimination from similar concepts 99
9.2.7 ask_strategy
If (and only if) a query for a strategy does not imply a proposal, we shouldannotate ask_strategy. As the term “strategy” is hardly ever used in such ques-tions (and in strategy discussion in general), it will often be unclear whetherthe question aims at a strategy or rather at a step; see again Example 9.1 (a). Wewill discuss this discrimination further in Section 9.3.7.
9.2.8 agree_strategy
The agree_strategy utterances we have seen were unambiguous; Example 9.2 (5)was the closest we saw to an ambiguous one. They tended to be quite short(e.g. “OK”) rather than longer, although longer ones occur as well, e.g. “OK.Good. Let’s do that.”.
9.2.9 disagree_strategy
We have seen only one instance of disagree_strategy: In Session CA2, at one pointC2 proposes “In principle, we could for now only change TableModel and leaveFeatureProxy as it is. We could.” (DPR: a rule to avoid touching FeatureProxy
for some time) and the partner remarks
“I don’t think we need to change the FeatureProxy.”
If this is correct, the strategy looses its basis, so the utterance should be con-sidered a disagree_strategy. If we assume the speaker is not quite sure whetherFeatureProxy needs change or not, we should annotate propose_hypothesis aswell; see Chapter 13, in particular Section 13.2.2.
9.3 Discrimination from similar concepts
9.3.1 *_strategy vs. explain_knowledge/explain_finding
Strategy proposals contain and represent knowledge. As a general rule in thebase layer for strategy proposals and their discussion (agree_strategy, challenge_strategy, amend_strategy, disagree_strategy, decide_strategy), strategy takes annota-tion precedence over both knowledge and finding. Justifications (if present) areannotated separately (that is, in addition to the strategy concept) and then useeither explain_knowledge or explain_finding. (This holds likewise for justificationsof other proposals or evaluations, most importantly for design and step).
9.3.2 propose_strategy vs. propose_todo
A propose_todo utterance remarks that one step needs to be done at some (usuallyundetermined) later time. In contrast, a propose_strategy of type OWP or EXS
100 Chapter 9. Process-oriented concepts: strategy
embeds at least two steps in a definite ordering and usually also suggests tostart that work now.
9.3.3 propose_strategy vs. propose_step
In Section 9.1 we have defined strategy as an idea for planful action. This ideais formed in a creative act that combines prior knowledge, assumptions, andrecent insights with an understanding of the goal hierarchy, the pair’s capa-bilities and limitations, and the current situation. The idea aims at producingadvantage: a solution for how to achieve a higher-level goal at all or achieve itmore easily than previous ideas. Reaching a higher-level goal is beyond a step-sized goal insofar it is an emergent property arising from multiple successfulsteps in combination.
In contrast, a step is considered (by the speaker) something simple: it has nointeresting structure and appears given rather than inventive. So it might seemas if the discrimination of step and strategy ought to be easy – and it often is,except when the following complications intervene.
9.3.3.1 Recycled strategies
The creative act required for inventing a strategy needs not have happenedright before: The strategy’s idea may be a reused one, previously inventedby the speaker or even a third party (think of practices such as test-drivendevelopment). This is a potentially important difference, but as the creative actas such is not often observable, the base layer prescribes to encode proposalsof recycled strategies just like fresh ones: as propose_strategy.
9.3.3.2 step with forward reference
Some proposals of work steps appear to imply that choosing this step willmake subsequent work easier. If that subsequent work and its connection tothe step are explained, such utterances are propose_strategy.
If, however, the reference is vague (e.g. a mere “Let’s first. . . ”), we call this astep with strategic character and annotate propose_step. Beware of hasty judg-ment: Utterances such as “Shall we tackle the simple cases first?” will often haveimplications that reach much farther, because they formulate a rule and aretherefore in fact DPR-type propose_strategy.
9.3.3.3 steps aiming at advantage
If the benefit intended by a proposal is evident, that does not mean it mustbe a strategy, because the benefit may not be advantage in the above senseof reaching a higher-level goal. Most steps with strategic character will have
9.3. Discrimination from similar concepts 101
evident benefit as well, but they are still atomic and hence still steps; seeExample 6.1 (b).
9.3.3.4 Multi-part proposals not forming a strategy
An utterance such as “Let’s start the program so we can test.” may look like pro-pose_strategy at first: One might think there are two steps (run, test) mentionedhere and they are integrated into a whole, so this could be a strategy? However,there is no inventive act here, no advantage needed to be devised, so this issimply propose_step. Furthermore, the illocution of the utterance (the speakerknows he is talking to a professional programmer!) is only “Let’s test” so therereally is no pair of steps at all.
9.3.3.5 The creative act is invisible
The inventive act is a nice theoretical criterion for a strategy, but is not oper-ationalizable: First, you cannot observe the actual creative act at all and onlysometimes will get to see symptoms of it. Second, the inventive act may noteven have happened in the present session; see Section 9.3.3.1 above.
9.3.3.6 Lowly creative acts
The creative act may be quite simple, relying far more on simply paying atten-tion to constraints rather than on producing a new idea (as in Example 9.2 (1)).
This creates borderline cases in which step and strategy become a matter of taste.Researchers may develop additional heuristics suitable for the data or theirresearch question in this respect, but should spend most of their energy ondiscriminations that are important for their work.
9.3.4 propose_strategy vs. propose_design
In Section 4.3.3 we have discussed that design proposals often imply (or comealong with or take the form of) step proposals. The inverse happens for strat-egy: Some pieces of a (typically OWP) propose_strategy may in fact be designproposals. In such cases, the respective sub-utterances should additionally beannotated with propose_design or amend_design. The same rule may then alsoapply during the subsequent discussion of the strategy proposal.
Worse, the discussion may turn from a strategy discussion entirely into puredesign discussion, which is important for the session and so should be reflectedin the annotations by stopping to use strategy concepts and using only designconcepts. We have not seen such a case so far.
102 Chapter 9. Process-oriented concepts: strategy
9.3.5 agree_strategy vs. agree_knowledge
If P1 makes a strategy proposal and provides justification and then P2 agreesmonosyllabically, it is unclear whether the agreement pertains to the proposal,only parts of the proposal, the justification, or several of these. You shouldnormally just annotate agree_strategy, except
• if the next few dialog steps show it was in fact an agree_knowledge for thejustification only or
• if knowledge transfer is a focus of your investigation.
In the latter case, a double annotation may be the safest route. See Example 9.3for a complicated case in which the proposal was actually a challenge_strategyand the justification comes separately.
Example 9.3: Episode from Session CA2 (12:58:29–12:58:52) contain-ing an ambiguous affirmation: Utterance 8 may pertain to utterance5 (unlikely) or 7 or both. C5 leans forward towards the display andsometimes turns toward C2; C2 leans back in his chair.
(1) C2.propose_strategy
“Then we should do that before or after. But not at the same time.”
Two alternatives are now on the table, plus a third marked as bad.
(2) C2.propose_hypothesis + C2.explain_knowledge
“Cause I fear that for this work task that we will exceed the time anyway,(.) because it will be fairly complicated.”
After four seconds of silence, C2 makes a prediction of how fast the furtherprocess will go and provides a justification.
(3) C2.decide_strategy
“Maybe one does it after?”
After another four seconds of silence, C2 suggests (in mode LO) a decisionhimself.
(4) C2.explain_standard of knowledge
“But I’m not sure myself either.”
Another two seconds later he emphasizes he does not trust his own judg-ment in this matter; see Chapter 14.
(5) C5.challenge_strategy
9.3. Discrimination from similar concepts 103
“I would do it (before).”
C5 prefers the other alternative.
(6) C2.agree_strategy
“Hmm, yea, I (!...!)”
C2 half-heartedly changes his mind.
(7) C5.explain_knowledge
“Because if we plan it for later, than, then, er (.), then it won’t happen.”
C5 justifies his preference with experience.
(8) C2.agree_knowledge/C2.agree_strategy
“OK?”The intonation clearly shows doubt. We cannot decide whether this justrepeats the previous affirmation or expresses (half-)agreement with the mostrecent explanation.
9.3.6 ask_strategy vs. ask_knowledge
Any open question specifically for a strategy will be annotated specifically withask_strategy, not generically with ask_knowledge.
9.3.7 ask_strategy vs. ask_step
We have now claimed several times that we can often decide between ask_strategy and ask_step only by considering the answer, not by looking at onlythe question itself. Unfortunately, this is still oversimplifying the matter, be-cause the respondent may have misunderstood the question or may evenhave intentionally misinterpreted it. Further context both before and after theutterance can often disambiguate such cases, but if the asker sits through amisunderstanding quietly, we may never know it.
Chapter 10Process-oriented concepts: state
10.1 Topic of state concepts
The state concepts represent utterances regarding the status or degree of com-pletion of working through the steps formulated or implied by a strategy. Therelationship between strategy and state is equivalent to the relation betweenstep and completion (Chapter 7). Like with the step referred to by a completionutterance, the strategy referred to by a state utterance needs not have beendiscussed or mentioned before, because the pair may be jointly following an“obvious”, tacit strategy, the driver may have had one in mind for a whilewithout mentioning it (for whatever reason), or a sequence of steps may berecognized as a strategy only after executing some of them. Therefore, stateutterances pertain to any evaluation of process progress above the step level.
Example 10.1: Some state utterances.
(a) ZB7: Z20.explain_state + Z20.disagree_step
“OK. (.) Now we have (!...!) This part is finished. This is (!!...!!) (.)Yesyes. No, no. We have changed the Topic. We did that earlier. Now wehave finished the Spy. This here still works as it did. Nothing has changedfor it.”
(interleaved with (b)). After a successful test of the previous changes,driver Z20 checks the progress in the requirements document and explainsit, pointing (Z19 has joined looking). Z19 interrupts him (as shown in (b)),but Z20 quickly disagrees and proceeds explaining before Z19 even startshis second sentence. Both of them shortly speak in parallel and eventuallyZ20 disagrees with the proposed step as well.
(b) ZB7: Z19.challenge_state + Z19.propose_step
105
106 Chapter 10. Process-oriented concepts: state
“No, no, wait. Not quite. We still need to transfer this part.”
(interleaved with (a)). Z19 interrupts the driver, pointing to an item in thedocument. The overall logical dialog sequence of this complicated exampleis Z20.explain_state, Z19.challenge_state, Z19.propose_step, Z20.disagree_step,Z20.explain_state (continued).
(c) BA1: B1.explain_state
“Yes, now we are (guess) finished, huh?”
After a set of important related changes (taking 30 minutes; Example 6.5 isan outtake) and their discussion, the driver states completion. The set ofchanges had not been formulated as a strategy beforehand, they appearedto follow one from the other in an ad-hoc manner.
(d) CA2: C5.explain_state
“As for checking in and so on, I think we are at a point where we can take abreak.”see Example 9.2 (6)
(e) CA2: C5.agree_state
“Of course, that’s true.”
answer to (d), see Example 9.2 (7).
10.2 state concepts and their properties
As shown in Figure 3.1, we have so far observed explain_state, agree_state, andchallenge_state.
10.2.1 Short agree utterances
Like other types of agreement utterances, agree_state statements tend to be short(“Yes.”).
10.2.2 Lack of reference to a strategy
As mentioned above, a state utterance does not necessarily relate to a previousstrategy utterance, let alone explicitly relate to it. Rather, it can relate to anycoherent sequence of work steps that as a whole would be considered non-atomic, whether explicitly annotated as a strategy or not. So far, no singleexplain_state utterance we have seen ever referred to a strategy explicitly.
10.3. Discrimination from similar concepts 107
10.2.3 Partial disagreement
A challenge_state will often challenge the “is completed” assessment of onesubtask (of several) only and may then come along with a propose_step (orperhaps propose_todo). Both are relevant, so a double annotation of challengeand propose should be used in such cases.
10.3 Discrimination from similar concepts
10.3.1 explain_state vs. explain_completion
The discrimination between explain_state and explain_completion rests on thediscrimination between strategy (or unspoken strategies) and step (or unspokensteps).
10.3.2 explain_state vs. explain_finding
This discrimination will be explained in Chapter 12.
Chapter 11Universal concepts: What is“knowledge”?
We have already used the term knowledge many times, but so far have beenvague about what it actually means in the base layer. We will explain this moreconcretely now.
11.1 On knowledge
Classic epistemology1 (going back to Plato2), considers whether knowledgecould be viewed to be the same as “justified true belief3”. This would meanknowledge to be related to a person and the statement “I know X” consideredto be correct if the following three conditions all hold4:
• X is true
• I am convinced that X is true (belief)
• I have good reasons to believe that X is true (justified)
For instance if I am about to toss a coin and state “I know that this coin will showhead” I may believe what I say and it may later turn out to be true, but the beliefis not justified and so it was not knowledge.
1http://en.wikipedia.org/w/index.php?title=Epistemology&oldid=5659951522http://en.wikipedia.org/w/index.php?title=Plato&oldid=5668368613http://en.wikipedia.org/w/index.php?title=Justified_true_belief&oldid=
5596916024The definition has many known limitations, but they have little relevance for our discussion
here. For our purposes, the justified true belief notion is a useful starting point.
109
110 Chapter 11. Universal concepts: What is “knowledge”?
For our purposes, however, this definition of knowledge does not work well,because each of the above conditions is problematic:
• The exact belief is usually not stated (only a rough approximation).
• The researcher can often not decide if a belief is true or not.
• The justification is often left unsaid and none may exist.
11.2 The base concepts’ notion of knowledge
As a way out we draw the following consequences for the base concepts: First,base-concept-“knowledge” requires belief, but it may be incorrect or unjustifiedor both. We still call it knowledge, because most of the time more informationis simply not available to the researcher. Even assumptions and hypotheses arebeliefs in this sense: we think of them as having a prepended clause “I am notsure but I think that. . . ”.
Second, although all of the utterances addressed by the P&P concepts are basedon something the speaker believes, this something is not considered knowledgeby the base concept set: We have decided to make separate concepts of the P&Pphenomena because we believe they are particularly important for the course ofa pair programming session and we have decided not to additionally annotatethe knowledge embedded in such utterances because we want to keep theannotation process lean and simple; see Section 21.4.
Third, any pair programmer has many many beliefs that are not covered byP&P concepts and will also not be considered knowledge in the sense of thebase concept set: For the reasons discussed in Section 2.3, only verbalizedbeliefs count as knowledge.
This notion of knowledge will in fact be split up into several concept classesfor representing utterances stating different types of belief that can be expectedto have specific interesting roles in the pair programming process:
• finding about recent insights (Chapter 12),
• hypothesis about partial beliefs (Chapter 13),
• standard of knowledge about what or how much the speaker knows or doesnot know (Chapter 14),
• gap in knowledge about something relevant that both pair members do notknow (Chapter 15), and
11.3. Priority rules for assigning knowledge concepts 111
• knowledge about everything else not covered so far (Chapter 16). Think ofknowledge as the final else clause in a long if-else-if chain. This definitionimplies we have now as many as four different notions of knowledgethat appear in this book
1. The vague, common-sense notion of knowledge.
2. The more specific term knowledge as explained in the present sec-tion.
3. The still more specific term knowledge as the thing underlying anutterance belonging to the knowledge concept class (in contrast tofinding, etc.).
4. The concept class knowledge for the respective utterances.
When you find the word knowledge, it will refer to meaning 4; when youfind the word knowledge, the context will make it clear which of theother meanings is the intended one, typically either 2 or 3.
The concepts from these concept classes are called universal concepts becausethey can be applied in discussion of product and process, not just one of these.Remember that the HHI base concepts only conceptualize verbalizations, sothey do not speak of knowledge that is not talked about. The rather peculiaractivity concept class (Chapter 17) is also universal.
To keep the number of concept classes low, the potentially very importantdiscrimination between fresh knowledge (finding) and previously existingknowledge (knowledge) is currently not made for the hypothesis, standard ofknowledge, and gap in knowledge concepts. Future research may need to changethis, in particular with respect to hypothesis.
11.3 Priority rules for assigning knowledge concepts
Whenever an initiative (as opposed to reactive) utterance is such that wecould annotate it as explain_knowledge, we will do so only as a last resort. Theresearcher will ideally be familiar enough with the various knowledge-relatedconcepts and the corresponding phenomena to recognize them directly. Ifthat does not work out in a particular case, one can walk down the followingpriority chain and use the the first concept class that applies:
1. propose_design/requirement/step/strategy/todo, explain_completion/state, re-member_requirement. The speaker believes the embedded knowledge tobe true or potentially true (that is, good enough to be worth a discussion).
2. propose_hypothesis. The speaker believes the knowledge to be likely-but-not-certainly true.
112 Chapter 11. Universal concepts: What is “knowledge”?
3. explain_gap in knowledge. The speaker believes the knowledge to be true.The same holds for all concepts further down the chain.
4. explain_standard of knowledge.
5. explain_finding.
6. explain_knowledge.
This priority list is simplified insofar as (a) ask concepts are not includedand (b) annotating more than one concept is sometimes appropriate (doubleannotation).
Chapter 12Universal concepts: finding
12.1 Topic and typology of finding concepts
As explained in Chapters 4 to 10, an insight that is verbalized only as a proposalfor the structure of product or process or as an assessment of work state (ortheir discussion) will not be annotated as finding at all. This is because the baselayer considers the proposal as such as more interesting than its origin from aninsight (a point of view your subsequent research may wish to change).
Of the remaining insights, as discussed in Section 11.3, any insight that falls intoone of the concept classes hypothesis, gap in knowledge, or standard of knowledgewill also not normally be annotated as finding. Utterances that rely on an insightfor justifying a proposal are one possible type of finding. Overall, the findingclass sits just before the final catch-all class knowledge as the next-to-last, quitegeneral concept class.
But what is a finding anyway? And how can we reliably recognize one, internalas it is, if only observations of actual behavior must be taken into account?
A finding is any result of a thought process that was found at least to a relevantpart as a recent insight or consequence of an insight. “Recent” means recentduring the current pair programming session and will typically lie within thepast minute. “Insight” is opposed to remembering.
• For an insight be annotated as a finding, it has to be verbalized as if it wasan undoubted truth.
• Replies of the type “Ah, now I understand” that merely signal the speakerhas understood the partner’s explanation of something do not count asfinding (rather as explain_standard of knowledge).
113
114 Chapter 12. Universal concepts: finding
• An insight that is verbalized once when it is fresh and again during laterepisodes of the session will be considered a finding the first time andknowledge later on.
• Spontaneous verbalizations of prior knowledge (explain_knowledge utter-ances that neither have a preceding ask nor a proposal context) presum-ably occur when the speaker had the insight that such explanation islikely useful. Such insights are not annotated as finding, only the explain_knowledge is annotated; see Chapter 16.
There is no complete, algorithmic method for recognizing verbalizations offindings. Rather, we present several finding verbalization types (which we willimprecisely call finding types); each defines a set of characteristics from whichan utterance should be classified as finding:
1. P: perceived event
2. D: discovered issue (subtypes DU, DC, DO)
3. T: thought (subtypes TB, TU, TC)
12.1.1 finding type P: perceived event
An utterance has finding type P if it verbalizes the recent perception (typicallyseeing or hearing) of events in the pair’s work environment, excluding utter-ances of the partner. A P finding utterance may direct the partner’s attentiontowards something, may include an interpretation or evaluation of the event(e.g. as welcome or unwelcome), or may potentially have still other roles.
12.1.2 finding type D: discovered issue
A finding has type D if it talks about passive information being observed. This istypically the verbalization of potential defects, problems, irregularities, or otherrelevant issues of the observed information or recognizable via the observedinformation. A general adequacy assessment or evaluation of a new or existingpart of an artifact also counts as a D finding.
Type-D findings usually require prior knowledge, but as usual the base layersuggests avoiding double annotations here unless your research question re-quires otherwise.
finding type D has three subtypes:
finding type DU: uncatalyzed discovered issue. The information observed isin an artifact, the finding pertains to development artifacts, and the findingwas not triggered or advanced by something the partner said or did or someother event in the environment.
12.1. Topic and typology of finding concepts 115
finding type DC: catalyzed discovered issue. Ditto, but the finding was trig-gered or advanced by something the partner said or did or some other event inthe environment.
finding type DO: observation. The information is not in an artifact or thefinding pertains to something outside of artifacts (such as the configuration ofdevelopment tools).
Example 12.1: Episode from Session CA2 (12:42:37–12:42:57)with several D-type findings. Driver C2 has opened classFeatureAttributeConfigurationProxy (which inherits fromAbstractFeatureAttributeConfiguration) and the pair reviews it. Thefindings pertain to a potential defect in the code.
(1) C5.explain_finding
“The get (..) (missing)”
A DU finding. After the pair had looked at the code of the class (which allfit on the screen), C5 remarks the absence of a certain getter method.
(2) C5.amend_finding
“It gets that from the Abstract.”
A DU finding. After two seconds of silence, C5 extends or elaborates hisfinding. He points to the class’ inheritance clause and apparently wants tomake the point that the method is inherited. He sounds like it should notbe.
(3) C2.amend_finding
“It mustn’t take the Abstract.”A DC finding. Interrupting him, the partner completes that thought: Itshould not be inherited.
(4) C5.agree_finding
“Yup.”
Immediate agreement.
(5) C5.propose_design
“You must overwrite it.”C5 suggests to implement their own local get method.
(6) C2.mumble_sth + C2.propose_step
116 Chapter 12. Universal concepts: finding
“It should never (!...!). Yes. What stuff is there in the Abstract? Let’slook.”C2 proposes to first review the full set of methods inherited from the super-class.
(7) C5.challenge_design
“In a sense, it shouldn’t inherit from Abstract really. Or we must nothave this in Abstract. One or the other.”C5 disagrees with overwriting the method and proposes to clean up thewhole inheritance construction instead.
12.1.3 finding type T: thought
A finding of type T is an utterance that verbalizes the results of thinking or sud-den (more precisely: apparently sudden) ideas and insights, possibly withouta recent triggering event or recently observed information. finding type T hasthree subtypes:
finding type TB: betterment. Utterances that correct (or find as incorrect) aspeaker’s own previous knowledge or finding utterance without external eventsthat appear to have caused that insight.
finding type TU: uncatalyzed idea. Utterances that verbalize spontaneousideas or insights that are not betterments and that occur without externalevents that appear to have helped create that idea or insight.
finding type TC: catalyzed idea. Utterances that verbalize spontaneous ideasor insights that are not betterments and that were preceded by an externalevent that appears to have catalyzed that idea or insight: The insight must besuch that it required taking into account additional information beyond thatcoming from the event and leading thought in a different direction than thatperhaps suggested by the event.
12.1.4 Priority rules for checking finding types
The finding types are part of the base layer (as primary characterizing attributesof the finding concepts), but are not stand-alone concepts within the baseconcept set. The purpose of the finding types, much like the proposal modesof Section 4.2.1 or the strategy types of Section 9.1, is to help with the decisionwhether to apply finding at all. For the finding types, this even takes the formof an if-else-if chain, much like for the knowledge-related concepts overall(Section 11.3) as follows:
• Assume you have worked through the Section 11.3 priority rules down
12.1. Topic and typology of finding concepts 117
to (including) gap in information without finding an appropriate conceptclass. So the utterance ought to be either of class finding or knowledge.
• Does it verbalize (and perhaps evaluate) a concurrent event? Then anno-tate a type-P finding.
• Does it verbalize an insight or evaluation relating to information currentlybeing viewed? Then annotate a type-D finding.
• Does it appear to verbalize a spontaneous insight or cogitation result?Then annotate a type-T finding.
• Otherwise either postulate a new finding type or annotate a knowledgeconcept.
Note that the finding types are not orthogonal; they overlap. This is becausethey only serve to decide what is a finding utterance, not to canonically classifyany finding utterance. Feel free to add your own (and even modify the existing)finding types where appropriate during your research.
Despite this help, reliably recognizing finding utterances tends to be difficult,because by their very nature findings have strong unverbalized components.
12.1.5 finding type indicators and examples
For examples of finding phenomena see Examples 3.1, 6.4, and 12.1 above,the compressed examples just below and Example 12.2 further down. Thecompressed examples serve to explain common symptoms and indicators fromwhich to recognize the finding verbalization type of explain_finding utterances.
finding type P applies to verbalizations of recent computer outputs. Examplefrom Session BA1: B1 has started an Eclipse search. While it is still running, B2comments “Two matches.”.
finding type P applies to evaluations of test run results. Example from Ses-sion CA2: After some code changes, the pair runs the application and manuallytests it. None of them says anything. After several steps, the driver concludes“There!”.
finding type DU applies to summaries regarding the quality of a part of anartifact the speaker has visibly just reviewed (see verify_sth in Section 19.4).Example from Session CA2: The driver announces he will inspect a certainmethod and runs down its lines with the mouse pointer while doing so. Nearthe end he states “Yes, fits.”.
finding type DU applies to utterances about some unusual property of apart of an artifact the speaker has visibly just reviewed. Example from Ses-sion CA2: While reviewing a method and running down its lines with the
118 Chapter 12. Universal concepts: finding
mouse pointer, the speaker reaches a variable declaration and says “This is anIFeatureProxiesTableModel, not a normal one”.
finding type DU applies to utterances that effectively state “I found what I waslooking for” at the end of the search for an item with some property. Examplefrom Session CA2: The driver wants to navigate to a method to be changed,but neither remembers its name nor the classname, so he looks through thecode of several plausible classes before the utters “Ah, there. (..) Exactly. (.) Thatis it, I think”.
finding type DC applies when the speaker explicitly points out a defect afterthe partner made a remark that apparently made the speaker recognize theproblem. Example from Session BA1: The driver attempts to decipher themeaning of an existing if condition and does not succeed. The observerprovides partial explanations that make the speaker recognize that his onlyproblem was that the code comment explaining the condition (that he himselfhappens to have written in an earlier session) was wrong. He says “Then I wrotethe wrong comment, only.”.
finding type DO verbalizes aspects of information freshly shown on the screenthat relates to the work environment itself, not the program artifacts nor theevents from test runs, etc. Example from Session BA1: Driver B1 opens the listof installed plugins in his IDE to check the status of the PHPEclipse plugin.No entry of this name exists and he asks rhetorically “What happened to myPHPEclipse that originally I had installed here?”
finding type TB applies to self-criticism regarding changes the speaker hadpreviously made on her own initiative. Example from Session BA1: The driverasks why two particular statements are not grouped together and then groupsthem without waiting for an answer. He ponders his change for five seconds(the partner still passive) before he says “Well, it’s not really nice like this”.
finding type TC applies to the following example from Session BA1: The driveradds a structured comment to a PHP function. As he writes “@return int”,the observer makes a “no” sound and the driver immediately states “There wehave our problem”. The function returns int at one point and boolean at another.The observer was aware of the boolean part; his utterance is disagree_activity(see Chapter 17) and a P-type explain_finding. This made the driver (who waspreviously more aware of the int part, but not exclusively so) recognize theproblem and state it as a a TC-type explain_finding.
finding type TC applies to a conclusion drawn from a previous knowledgeutterance of the partner. Example from Session CA2: Observer C2 suggeststo use the Alt-Shift-C key combination, but C5 explains that that would dosomething different (having to do with constants). C2 checks this against hisown keystrokes knowledge and concludes “Then you have changed that”; seeExamples 16.2 and 16.4 for details.
12.1. Topic and typology of finding concepts 119
Any finding type may apply if the speaker emphasizes an insight explicitly bylinguistic means such as “Now I understand. . . ”, “Oh, wait. . . ”, “Aaaahhh!”, etc.
Examples for this from Session BA1: The driver comments on the name ofa function he has been editing “I just recognize that’s total bullshit, that name”.Elsewhere he says “Aahh, we don’t want to reduce traffic really, of course, we wantto save write accesses to the remote side. That’s the whole trick: That they don’t updatesomething that is up-to-date anyway”. At still another time the observer says “Oh,Account!”. From their context, we can recognize these as DU, TC, and P findingutterances, respectively.
Example 12.2: Episode from Session BA1 with many findings. A num-ber of code changes have been performed so that the PHP script shouldonly return those database entries modified in a given time interval.For testing, the pair had enforced a particular time-difference by hard-coding, then removed that code again just before this episode. All utter-ances but one come from B1.
(1) B1.propose_step
“And now we’d said we could run a little simulation now.”B1 suggests to do a realistic test call from the browser and performs it rightaway.
(2) B1.explain_finding
“Now we return files (.). That means the last change (.) was after thequery.”
finding type P: He verbalizes the result that appears in the browser (a listof strings each containing one hexadecimal result value) and interprets it ashaving a particular property.
(3) B1.propose_step
“Stop, wait. After the last query?”
A rhetorical question after several seconds of silence. Its meaning is “Let usconsider whether my interpretation was indeed correct.”
(4) B1.ask_knowledge
“What do we hand over really as timestamp[last_request]?”
B1 has switched back from the browser into the IDE where the if-conditionis still marked that determines the return value. It is unclear whether hisquestion asks for the current value of the variable or for its general mean-ing.
120 Chapter 12. Universal concepts: finding
(5) B2.explain_knowledge
“Well, that’s where the (~remote side) hands over to us (.) its Timestamp
(..) when it last (~modified) the (~FriendslistId).”
B2 explains the semantics of the variable without hesitation.
(6) B1.agree_knowledge + B1.ask_knowledge
“Right, but what is our script doing now?”
B1 agrees immediately; he has apparently known this before. He asks aboutthe behavior in the current specific case.
(7) B1.explain_finding
“I gave it some arbitrary Timestamp (;;;) I’m surprised that it worked with-1000, +1000.”
After four seconds of silence, B1 formulates the insight that the Timestamp
he submitted to the test run was not chosen in any particular manner andso the script should not have returned the expected results like it did. Thescreen still shows the IDE initially and B1 switches back to the browserwhile speaking and marks the relevant part of the URL. The insight mayhave arisen earlier: before step (3). The numbers -1000, +1000 refer to pre-viously hard-coded values that were actually -100, +100 and had been re-moved before.
Even with the many explanations we provide, the content of the example isdifficult to understand, which illustrates how much context understandingmay be needed for annotating even the base concepts properly.
12.2 finding concepts and their properties
As shown in Figure 3.2, we have observed explain_finding, agree_finding, dis-agree_finding, amend_finding, and challenge_finding.
Many properties of finding utterances have already been explained in theprevious section. We will not repeat those here, only discuss more specializedones.
12.2.1 Aggregation of utterances
If an utterance contains what could be viewed as several (but related) find-ings, we still annotate only one explain_finding to avoid unnecessary decisiondifficulty. You might want to drop this rule if findings are a focus of your inves-tigation. If the findings appear unrelated, the utterance should be consideredtwo utterances and annotated separately.
12.2. finding concepts and their properties 121
12.2.2 Repeated statements
If the same finding is apparently verbalized more than once in similar orparaphrased form, we consider the following cases depending on who repeatsand when:
• Same speaker shortly afterwards: Annotate the second utterance withexplain_finding again.
• Different speaker shortly afterwards: Decide which of the following isthe most likely meaning of the utterance:
– “OK, I understand your idea”; this would be annotated as explain_standard of knowledge.
– “OK, I understand your idea and think it is correct”; this would beannotated as agree_finding.
– The speaker had the same idea as the partner at essentially the sametime; this would be annotated as another explain_finding.
• Same or different speaker a long time later: If the utterance shows symp-toms of a fresh finding again, it should again be annotated as explain_finding. Otherwise, the previous finding should now be considered priorknowledge and be annotated as explain_knowledge.
12.2.3 Thinking aloud
Some developers sometimes verbalize substantial parts of their thinking pro-cess in real time. For instance we found this long utterance in Session BA1:
“First change zero (!...!) (..) The problem is if it returned the currentTimestamp (!...!) (..) (Hm.) (.) We have a problem anyway that we keepthe clocks in sync. (.) And if we take the Timestamp now it could happenthat by a few seconds, milliseconds (!...!) (.....) No, seconds. That it lagsbehind by one, two seconds and (.) that we send something unnecessarily.”
The utterance is far from contiguous (it has long pauses), but it is coherent anduninterrupted and is hence considered a single utterance rather than several.Unless some of its parts have to be annotated as explain_standard of knowledge(see the discussion in Chapter 14) or explain_knowledge (see the discussion inChapter 14), we will annotate such cases simply as explain_finding.
122 Chapter 12. Universal concepts: finding
12.2.4 Revoking and replacing findings
Just like we saw speakers amend or revoke their own design proposal (seeSection 4.2.6), we saw speakers revoke their own finding and replace it byanother. Such utterances should be annotated as challenge_finding. Do not beconfused if the new version states prior knowledge: The fresh insight is thatthis is (subjectively) correct. See also the discussion in Section 21.6.5.
12.2.5 “Additional” findings
It is often difficult to decide whether an utterance is “merely” an addition ordetailing of a previous finding (with or without elements of a new insight,but which should be annotated as amend_finding) or an entirely new one (andshould be annotated as explain_finding). As in many similar places in the baseconcept set, we err on the side of reducing complexity and will always annotatesuch cases as amend_finding, no matter which speaker. Subtle cases arise in thecontext of knowledge and will be discussed in Chapter 16.3.
Example 12.3: Episode from Session BA1 (14:44:21–14:44:52) in which aspeaker amends his own previous finding. The episode also shows howto detect proposals (design in this case) in finding contexts.
(1) B1.explain_finding
“I just recognize that’s total bullshit, that name.”
finding type DU: B1 has added a comment on functionregisterFriendsLastChange and now evaluates the function name.
(2) B2.ask_knowledge
“Why?”
The observer promptly wants an explanation.
(3) B1.propose_design
“Either registerFriendsChange (!...!)”
Almost interrupting the partner (and not answering his question), B1 pro-poses how the function should be named. This is an elaboration of thefinding, but also a propose_design which takes annotation precedence. Hestarts to offer two versions but stops after the first (perhaps due to anotherinsight, but this is not relevant at this point).
(4) B1.amend_finding
“Ah, (.) you know, (~FriendsLastChange) is total nonsense somehow so’cause we register, somehow, that this event occurred.”
12.2. finding concepts and their properties 123
After three seconds of silence, B1 elaborates on his insight. “Ah” signalsanother finding, but its close relation to the initial one makes us annotate itas amend, not explain.
(5) B1.challenge_design
“What do you think of (..) UpdateFriendsLastChangeTime?”
Without a pause, B1 makes another naming suggestion different from his(incomplete) previous one. He starts performing the renaming even as hespeaks.
(6) B2.agree_design
“Wonderful.”
B2 accepts the second proposal.
(7) B1.amend_finding
“’cause that’s the nice thing about it is (..) (~that it’s different here every-where). Here we have it and here we update it. And that is clean I guess.”
Although B2 has not asked, B1 immediately explains his reasoning. Bothtimes the “here” is supported by pointing the mouse. This sounds morelike an elaboration than like a new insight, so we annotate it as amend_finding.
(8) B2.agree_finding
“Good.”This could refer to many things so we consider it as referring to the tempo-rally closest of them.
Example 12.4: Episode from Session BA1 (14:23:59–14:24:38) in whicha speaker amends the partner’s finding. It also serves as an example ofhow even difficult acoustic conditions do not always prevent properannotation.
(1) B1.propose_step
“Er, I’d say, we go copy everything here bad-ass.”
The pair wants to implement the function getFriendsLastChange whichcurrently has an empty body. B1 suggests to start from a copy of the wholebody of function getFriendsIDs. He scrolls to the top of that body whilehe speaks.
(2) B2.propose_design + B2.explain_finding
124 Chapter 12. Universal concepts: finding
“The SQL we don’t need anymore. Because we only have an a Memcache
query.”
After one second, B2 remarks that the first statements of the body will notbe needed and explains why. Meanwhile, B1 starts copying the body.
(3) B1.agree_design/B1.agree_finding
“Exactly.”
B1 immediately agrees in full; apparently, this was not new information forhim.
(4) B1.propose_step
“I’ll delete it in a second.”Three seconds later, the copying is still going on, B1 explains how he in-tends to handle the issue.
(5) B1.explain_finding
“What are these TABs here?”B1 reports that he has stumbled over some incorrect source code formatting.Could as well have been annotated as ask_knowledge. The utterance has noconsequences in the episode.
(6) B1.explain_finding
“If not dollar id?!”
After finishing the copying ten seconds later, B1 reads a line of code fromthe screen: if (!$id). The pronunciation sounds like he has found anirregularity, not like an actual question.
(7) B2.mumble_sth
“Return array, ne, (~~), (null)”
This appears to talk about the loop body: return array();. The middlepart is incomprehensible because B1 talks at the same time.
(8) B1.amend_finding
“(crap)”
B1’s adequacy assessment for the if clause.
(9) B2.amend_finding
“(~) Dollar id so-and-so (~)”
12.2. finding concepts and their properties 125
Much of the utterance is incomprehensible, but the understandable partclearly references the previous explain_finding and the partner’s reactionshows he has understood. We therefore annotate this utterance as amend_finding.
(10) B1.agree_finding
“Yes, exactly.”
B1 has apparently understood without problem and immediately agrees.
12.2.6 Justifications of proposals
As discussed in previous chapters, when a rationale or justification is providedalong with a proposal, this will usually be annotated as explain_knowledge.Sometimes, however, this knowledge will be fresh and then explain_findingis the appropriate concept. The rules for discriminating these two in thisparticular context will be discussed in Chapter 16.
12.2.7 Justifications of findings
If a finding and an accompanying explanation or justification are stated in asingle utterance, without a longer pause and without an intermediate utterancefrom the partner, they are annotated as one single explain_finding (or amend_finding or challenge_finding), because it is impossible to decide whether theyrepresent a single insight or not.
We usually ignore whether or not prior knowledge is part of the explanation;specialized studies may want to change this decision.
12.2.8 disagree_finding, challenge_finding
Just like for other objects, the partner may reject a finding with either disagree orchallenge.
disagree_finding: The speaker does not provide information beyond the rejectionitself. Actual cases of this infrequent behavior may take curious forms. Forinstance in Session CA2, C5 had said “It needs to do a rebuild – it is rebuilding rightnow” (explain_finding), which C2 rejects without explanation by saying “That hasnothing to do with the taskbar not working” (disagree_finding); see Example 19.4 formore context. This reply is just as illogical as it sounds, the underlying problembeing that C2’s previous complaint about the taskbar had been completelymissed by C5. The rules of annotating base concepts know nothing of suchmishaps, so we simply annotate disagree_finding.
challenge_finding: The speaker suggests either a different finding or a reasonwhy the partner’s finding is likely incorrect. The former can either lead into
126 Chapter 12. Universal concepts: finding
agreement or into controversy. The latter can either lead into controversy orinto a state where the pair is left with no valid finding at all, as in the followingexample (we will come back to this topic during the discussion of challenge_knowledge in Section 16.2.9):
Example 12.5: Episode from Session ZB7 (16:15:39–16:15:48) in whichthe speaker rejects his partner’s finding. The annotation does not reflectwhether the rejection involves prior knowledge.
(1) Z19.explain_finding
“No, with the lib wasn’t right, there had to be ’dot dot’ there.”
The pair works through the file build.properties and the build errormessages on the Eclipse console. The observer suggests that the linelib.dir=$basedir/lib should in fact be lib.dir=$basedir/../lib
(2) Z20.challenge_finding
“That cannot be. The lib is lying here, too.”
The driver immediately replies why this cannot be true, but neverthelessmakes the suggested modification. This behavior points out a boundaryof the base layer: it does not express such inconsistency between speakingand action.
(3) Z19.agree_finding
“Yes, right. Then it wasn’t the problem.”
The observer withdraws his original finding.
The rejection is not always explicit, it can also be implicit in a propose in whichcase we perform a double annotation as in the following example:
Example 12.6: Episode from Session CA2 (12:39:27–12:39:52) in whichthe speaker rejects his partner’s finding implicitly by proposing some-thing that would not be needed if he agreed.
(1) C2.explain_finding
“Good.”C2 has started a test run to see if a certain attribute table works as in-tended. He accesses the menu, displays the table, then displays the at-tributes, then makes this utterance which confirms the test as successful.
(2) C5.propose_step/challenge_finding
“Do (..) please change the values (.) and go there again.”
12.2. finding concepts and their properties 127
C5 suggests that modifying the attribute values should be tested as well.This is primarily a propose_step, but implicitly also refuses the partner’s“Good” conclusion as premature. The challenge_finding (as opposed to dis-agree) takes the view that the proposal explains what needs to be donebefore the finding can become justified.
(3) C2.agree_step/C2.agree_finding
“Um. (.) Yes.”
C2 agrees immediately (almost interrupting C5’s utterance). He modifies anattribute value, closes all attribute tables, and reopens them.
(4) C5.explain_finding
“(OK.)”
The observer recognizes that the table still contains the previous value. Hisutterance is fairly quiet.
(5) C2.explain_finding
“Okayyy, doesn’t work.”
A moment later the driver also states that something is wrong. We anno-tate this as explain_finding rather than agree_finding because C5’s utterancewas quiet and C2 stared at the screen transfixedly at the time and has pre-sumably not heard it at all.
(6) C5.propose_step
“(Let’s look.)”
The observer asks (but quietly) to see the code.
(7) C2.propose_step
“Theeeeeen we should look why.”
Two seconds later, the driver proposes the same. Again he has apparentlynot heard his partner.
12.2.9 Reasons for agreement
As in the other concept classes, agree_finding utterances tend to be short. Insome cases it is helpful to consider three possible situations in which thespeaker expresses his or her agreement:
• known: The agreement may express “I knew this already since some time”(in the sense of prior knowledge as opposed to a finding). See for instance
128 Chapter 12. Universal concepts: finding
the first agree_finding in Example 12.4. In principle, such utterances areexplain_standard of knowledge, but we give the existing finding contextpriority unless there is a rather explicit declamation of a standard ofknowledge.
• understood: The agreement may express “I did not know this, but I under-stand what you say and now I think so, too”. For instance, in Session BA1,B2 explains “You haven’t passed any parameters” to which B1 replies with ahappy “Right!”.
• me-too: The agreement may express “I just had the same insight”. Forinstance, again in Session BA1, B1 explains “The problem is when you stopthe script here (.) then (.) the request will not get a response. (.) Or though thenit will send its standard header and also (~not) send anything” to which B2replies “I suppose so” (which is not a hypothesis utterance because we arein a finding context already).
Like the proposal modes in Section 4.2.1, the strategy types in Section 9.1, andthe finding types in Section 12.1, these agreement types are primary characteriz-ing attributes but are not themselves stand-alone members of the base conceptset and you need not be able to annotate them consistently; they serve only tomake it easier to understand whether a particular utterance is an agree_findingor not. We have not found a similar discrimination necessary for refusals so far.
12.2.10 Doubt
Agreements to findings may involve visible or audible doubt: The speaker isonly half convinced. We will discuss this issue in Section 21.6.4.
12.2.11 ask_finding?
There is no base concept ask_finding, because the asker just needs informationand will usually not care whether the underlying knowledge is new or old.(Exceptions are possible, for instance mentors might ask questions that aim attriggering findings.)Therefore, expect to see episodes in which ask_knowledge isfollowed by explain_finding or a similar pattern as in Example 12.7.
Example 12.7: Episode from Session BA1 (15:17:14–15:17:42) which isthe closest we ever came to introducing the concept ask_finding. How-ever, strictly speaking the asker cannot know (and likely will not care)whether the requested knowledge is old or new, so we stick with the ex-isting ask_knowledge instead. The example also illustrates amend_finding.
(1) B1.explain_finding
12.3. Discrimination from similar concepts 129
“The last Request here, (;;) last and here, er, change and thus (!...!) Yes,right. Yes, now we get a friends list.”
The driver thinks about what a certain if statement will produce in the sit-uation currently considered. He takes notes on a slip of paper and partiallyarticulates his thoughts. As a result, he formulates the insight that the setof friends of a certain person will be computed.
(2) B2.challenge_finding
“No, we don’t get a friends list.”
B2 immediately contradicts B1 by postulating the opposite.
(3) B1.challenge_finding
“Yes, we do get one.”
B1 repeats his original claim. (The reaction shows that B2.challenge_findingis more appropriate than B2.disagree_finding above; see Section 21.7.3.)
(4) B2.ask_knowledge
“Why? If (!!...!!)”
B2 demands a justification (and B1 interrupts the question early). As thejustification of an insight is likely part of that insight or another insight,this could have been called ask_finding but for the reasons explained abovewe have not introduced that concept.
(5) B1.amend_finding
“100 seconds after their last query we have (.) 100 seconds after their lastquery we have changed something (..). So we have changed something afterthey last asked. So they now get a fresh answer.”
B1 explains his insight by providing details.
12.3 Discrimination from similar concepts
Discriminating finding concepts from product-oriented and process-orientedconcepts is guided by the principle that the latter classes take priority asexplained in Section 11.3 and the principle that knowledge transmitted alongwith process/product concept utterances is not annotated separately (onlyjustifications are) as explained at the end of Section 3.6.
The remaining issues are discussed in the subsections following below.
130 Chapter 12. Universal concepts: finding
12.3.1 finding vs. other universal concepts
Most ideas for discriminating finding from knowledge were already explained inSection 12.1 above and the rest will follow in Chapter 16 about the knowledgeclass. Discriminating finding from the other classes of universal concepts willbe discussed only in the respective chapters.
12.3.2 explain_finding vs. propose_design
See Section 3.7, Section 4.2.3, and Section 12.3.3.
12.3.3 explain_finding vs. *_step
For propose_step, see Section 6.2.1. If a speaker explicitly marks an insight as partof a step utterance, this is annotated as an additional explain_finding. We haveseen such behavior when the speaker, after a proposal had been formulated,has perceived something that suggests the proposal was unsuitable (as inExample 6.1). The same rule should be applied to the other product-orientedand process-oriented concepts, but we have not seen such phenomena so far.
12.3.4 explain_finding vs. explain_completion or explain_state
explain_completion and explain_state are both special cases of explain_finding andtherefore take annotation precedence.
Chapter 13Universal concepts: hypothesis
13.1 Topic of hypothesis concepts
A hypothesis in the sense of the base concepts is an utterance relating to aconjecture, assumption, or hypothesis that the speaker observably doubts tosome degree. It may be that the speaker expects it (or sometimes its opposite)to be true more likely than not or that no particular conviction is present. It canbe new (a doubted finding) or old (uncertain knowledge). Actual verificationof the hypothesis needs not be practical for the pair.
We have seen the following three types of hypothesis utterances, but moremay exist. For examples see Section 13.1.4 which lists the types of issues thathypothesis utterances tend to talk about.
13.1.1 Uncertain knowledge
A hypothesis of type ’doubted’ pertains to something that could (and oftenshould) be part of the speaker’s existing knowledge but that is available onlypartly, making the speaker doubt it. For instance, relevant detail may be lacking,the speaker may be only half-convinced of the correctness of his or her memory,or the knowledge is altogether vague. Such a hypothesis is not specific to thecontext of the current session.
13.1.2 Hard-to-verify assumptions
A hypothesis of type ’hard-to-verify’ pertains to something that either takes a lotof effort to check (beyond what is practical in the current session) or that thespeaker does not know how to check or that can only be verified by waitinga long time (beyond the length of the current session) to see how the worlddevelops.
131
132 Chapter 13. Universal concepts: hypothesis
13.1.3 Readily verifiable conjectures
A hypothesis of type ’can-check’ pertains to something that the pair is able tocheck within the current session. It is not important if they actually do.
13.1.4 Issue types addressed by hypotheses
We have seen the following types of topics (issue types) occur in hypothesisutterances, but more may exist.
Program execution properties. Hypotheses about what happened in a recentprogram execution or what may or will happen in a future one. For example,a few seconds after a NullPointerException has terminated a run in SessionZB7, Z20 comments: “You know what happened? (...) I guess (no) (.) I don’t knowbut I guess (..) that the receive didn’t receive anything after 10 seconds.” (typecan-check). And in Session BA1, after the pair has modified a call argument,the observer speculates about the effect “Is bigger. (So we) should get an exit, nota friends list, right?” (type can-check). Such utterances can have any hypothesistype but will often tend towards can-check.
Environment properties. Hypotheses regarding properties of the variousdevelopment tools used, the networking environment, etc. For example, whilethe pair investigates configuration issues in Session ZB7, Z19 comments “Does,er, (!...!) I think XDoclet butchers that (..) perhaps?” (type can-check). And inSession BA1, after a call to the wget utility failed, the observer has an idea whyand asks “Firewall?” (type can-check). Such utterances can have any hypothesistype but will often tend towards can-check.
Program artifact properties. Hypotheses regarding properties of the programthat are formulated in terms of the program text and related artifacts. Forexample, after a test run yielded the wrong result in Session BA1, B2 utters“Safe::id_to_code. Probably some old bracketing error” (type can-check). And inSession CA2, before moving a class to a different package, C2 proposes ajustification “This is probably not used here anymore” (type is unknown). Suchutterances can have any hypothesis type.
Process course. Hypotheses formulated about properties of past or futuredevelopment activities. For example, after the n-th failed change-build-testcycle Z20 says in ZB7 “Perhaps we should have made a real undeploy” (type can-check). And in Session CA2, C2 justifies a strategy proposal by saying “Cause Ifear that for this work task that we will exceed the time anyway, (.) because it will befairly complicated” (type can be considered can-check or hard-to-verify). Suchutterances can have any hypothesis type.
Conventions. Hypotheses about general conventions (often regarding for-matting or naming) that the pair is expected to follow. For example, after C5has started filling the comment field during an SVN commit operation with
13.2. hypothesis concepts and their properties 133
“cad-507” in Session CA2, C2 interjects “I think the ’cad’ is upcased or so?” (typedoubted). Such utterances will usually have hypothesis type doubted.
13.2 hypothesis concepts and their properties
As shown in Figure 3.2, we have observed propose_hypothesis, agree_hypothesis,disagree_hypothesis, challenge_hypothesis, and amend_hypothesis.
13.2.1 propose_hypothesis
propose_hypothesis represents utterances in which the speaker states how some-thing could be explained or what properties something might possess. For thischaracter, the verb propose appears more appropriate than explain, so this iswhat we use.
13.2.2 agree_hypothesis, disagree_hypothesis, challenge_hypothesis
agree_hypothesis represents any utterance by which the speaker expresses thathe or she believes the proposed hypothesis is correct more likely than not. Forexample in Session CA2, C5 explains where he thinks the pair can obtain arequired task ID by saying “Well I think <**Developer**> has it in his Opera” towhich C2 agrees with a quiet “(OK)”. If the utterance also explains why thespeaker agrees, this is expressed by annotating explain_knowledge or explain_finding in addition. For example, in the episode from Session ZB7 we knowfrom above, Z20 hypothesizes “You know what happened? (...) I guess (no)(.) I don’t know but I guess (..) that the receive didn’t receive anything after 10seconds” and Z19 replies “Yes, it took a while, right”, which we annotate as agree_hypothesis+explain_finding.
Note that this style of annotation loses the relationship between agreementand explanation, so you might want to extend the modeling if that aspect isimportant for your particular study.
Likewise, disagree_hypothesis represents any utterance by which the speakerexpresses that he or she believes it is more likely than not that the proposed hy-pothesis is incorrect. If the utterance also explains why, this is again expressedby annotating explain_knowledge or explain_finding in addition. For example inSession ZB7, Z19 appears to believe that the failing of the previously run testmost likely occurred because not all required configuration settings had beenmade by the pair; he is leafing through a configuration documentation. Hevaguely states his hypothesis as “Yes, er, to get (.) to get that running we need todo certain things and something is missing of that”, but Z20 disagrees by saying“But we DID do all that” (disagree_hypothesis/explain_finding).
Had the speaker disagreed and offered an alternative hypothesis, this shouldhave been be annotated as challenge_hypothesis.
134 Chapter 13. Universal concepts: hypothesis
13.2.3 Conditional agreement
Sometimes the speaker says something of the type “If we find condition X tohold, then I agree with your hypothesis”.
For instance in the example of Section 13.1.4, Z20 says “Perhaps we should havemade a real undeploy” and Z19 replies “If it still doesn’t work now, we can do it”. Weconsider such conditions that do not modify the hypothesis as such to be partof the agreement and annotate the above utterance as agree_hypothesis/propose_step.
13.2.4 Revoking or replacing one’s own hypothesis
Like for explain_finding (see Section 12.2.4), we found cases of explain_hypothesiswhere the speaker takes it back a short time later. Sometimes, the speaker sim-ply appears to lose confidence in the former idea; for example in Session CA2,C2 proposes “Because it could be that it’s just this one AttributeConfigurationthat we don’t have added yet” and then adds “But (.) I don’t think so” (disagree_hypothesis).
In other cases, a “better” idea appears (from discussion or simply from furtherthinking) and the hypothesis is replaced by a supposedly superior one; forexample in Session CA2, C5 first proposes “That should, we must, the demo downhere <*points to a class*> (.) it ought to be in there, the EditColumnAttribute” andthen has a 12-second discussion with his partner, during which the class is notopened, and concludes “Stop, no, then it must be up here <*points to a differentclass*>, right?”. Such cases are annotated as challenge_hypothesis.
13.2.5 amend_hypothesis: One hypothesis or several?
If a subsequent utterance refers to a previously proposed hypothesis, and is notsimply agreement or disagreement, it is not always clear whether it proposes anew hypothesis or refines the previous one. If it proposes a new hypothesis, thatmight be an additional one (propose_hypothesis) or an alternative one (challenge_hypothesis). If it refines the previous hypothesis, it should be annotated asamend_hypothesis.
We use the following criterion for deciding when to encode with amend: If theoriginal proposal can be paraphrased in the form “If A, then B”, then we useamend if the new utterance widens the condition (“If A or A2, then B”), narrowsdown the condition (“If A and A2, then B”), loosens the consequence (“If A,then B or B2”), or extends the consequence (“If A, then B and B2”).
Such utterances do not appear to be frequent; we have not seen any singleinstance of them. The only reason that amend_hypothesis is part of the baseconcepts nevertheless is Example 13.1 which, with a little stretching of theabove definition of amend_hypothesis, could be considered to contain one.
13.2. hypothesis concepts and their properties 135
Example 13.1: Episode from Session ZB7 in which driver Z20 stateshypotheses and supporting justifications. One justification is anotherhypothesis, the other comes from existing knowledge.
(1) Z20.propose_hypothesis
“I think these dot dot there are wrong. (..) And it could be that I had setthem on my machine.”
While discussing the reasons for the failure of a previous build pro-cess, the pair looks at a configuration entry of the form conf.dir =
$basedir/../conf. The driver conjectures that the ’go to parent directory’part of the path is wrong (H1). He adds another conjecture H2 that this set-ting was correct on his machine (from which it was taken) but is inappro-priate for the setup of the present machine. The second hypothesis servesto support the first and we decided to consider them one single hypothesisin our annotation.
(2) Z20.mumble_sth
“I, er (!...!)”
The driver removes the ’../’ part from three such paths in the configurationfile.
(3) Z19.ask_knowledge
“Are these all files so, not?”
Z19 asks if corresponding changes need to be made elsewhere.
(4) Z20.propose_hypothesis
“Hm, hmmmm. No, that is only (.) here it should be proble(.)matic.”
Z20 does not appear to be sure; the reply is another conjecture (H3).
(5) Z20.explain_knowledge+Z20.propose_hypothesis
“Cause I had the project different before. The basedir I think is the Eclipseproject.”
Z20 justifies his former hypothesis. The first part is existing knowledge,the second part is another hypothesis (H4). We view H4 as an additionalhypothesis here, but if we would construe the first statement above to havethe shape “If H2, then H1”, then we could take the present one as refiningit into “If H2 and H4, then H1” and accordingly annotate it with amend_hypothesis.
(6) Z19.explain_standard of knowledge+Z19.agree_hypothesis
136 Chapter 13. Universal concepts: hypothesis
“Ah, now I see. You are right.”
The second part formulates agreement – it is not fully clear to what. Thefirst part does not sound like a very local statement, so it makes sense toassume the agreement covers more than only H4, which is another argu-ment why amend_hypothesis might be an appropriate annotation above.
13.2.6 Justification of hypotheses
Not only agreements and disagreements (as in Section 13.2.2) but also thehypothesis proposals themselves often come with a justification. Depending onits content, this justification should be annotated separately as either explain_knowledge, explain_finding, or propose_hypothesis. Do not confuse parts of thehypothesis (such as conditional clauses) with justifications.
13.2.7 Justification by hypotheses
A hypothesis may also serve as justification for any other proposal (not justa hypothesis), as well as as justification for various types of explain and otherutterances.
13.3 Discrimination from similar concepts
Most interesting is the discrimination from finding and knowledge concepts. Theformer is discussed below, the latter will be discussed in Chapter 16.3.
13.3.1 propose_hypothesis vs. explain_finding
A hypothesis will often be of recent creation rather than being part of existingknowledge and then represents an insight (finding). So when do we annotatepropose_hypothesis rather than explain_finding in such cases? We have definedthat the main criterion is incomplete conviction of the speaker: A finding isconsidered true, a hypothesis is considered uncertain. But how to discriminatethose cases?
Indicators for the hypothesis-ness of an utterance are words such as think,hope, guess, expect (and others) or the use of question form. But neither doall hypothesis utterances exhibit those features nor do all finding utterances lackthem – “think” in particular is highly ambiguous:
“Ahh, I think it has this (!...!) it does not accept this as a PHP project.”
In this quote from Session BA1, the insight character is obvious, but the degreeof conviction is not.
13.3. Discrimination from similar concepts 137
The only solution is judging, from the context before and after the utterance,whether the speaker appears to be (at the time of the utterance) convinced ofthe truth of the assumption or not. In the above case, our analysis decided yesand we hence annotated explain_finding.
Studies that pay major attention to validation-of-knowledge processes in pairprogramming will definitely need to create finer instruments for diagnosingand expressing what is going on in the session than the base layer provides.
Chapter 14Universal concepts: standard ofknowledge
14.1 Topic of standard of knowledge concepts
The standard of knowledge concepts represent utterances in which the speakerqueries the partner’s or explains his or her own level of currently availableknowledge: Whether a particular piece of knowledge is consciously presentor how much knowledge about a certain topic is available (or missing). Theutterance does not aim at communicating the content knowledge itself.
These utterances talk about the knowledge of a single pair member, not thepair as a whole (see gap in knowledge, Chapter 15, for the latter). The standardof knowledge concepts exist because we found they serve important roles inthe pair programming process; explain_standard of knowledge typically preparesor rejects or acknowledges a knowledge transfer. The following subsectionsexplain these three different standard of knowledge utterance types.
14.1.1 PT: Preparing knowledge transfer
The speaker states that he or she lacks certain knowledge (and perhaps ex-plains what that knowledge would be about), implying (or stating) that thisknowledge would need to be transferred to him or her. It is not importantwhether that transfer then actually happens or not or even whether it wouldbe feasible. There are three subtypes:
PTd, for decision: The speaker explains to what extent he or she possessesknowledge sufficient for decisions to be made soon.
For example in Session CA2, C2 has just stated that he thinks a Facade shouldbe introduced into the program to hide some details and then continues “What
139
140 Chapter 14. Universal concepts: standard of knowledge
the Facade looks like I don’t know. That I don’t yet, I don’t (.) yet see”.
PTe, for execution: The speaker explains to what extent he or she possessesknowledge sufficient for performing certain activities (often a step) requiredsoon.
For example in Session CA2, the pair needs to determine the official task ID oftheir current work goal and driver C2 says “(~Could) you just look? I have noidea how I would (!...!). Don’t know by heart”. The solution suggested explicitlyin this utterance, that the better-informed partner next take the driver role, isoften tacitly applied to resolve such situations.
PTo, other: This is the catch-all type for knowledge transfer triggers that donot immediately pertain to decisions or actions.
For example in Session BA1 during a sequence of connected simple changes,B1 states that he momentarily lost and then presumably re-established hisorientation: “translate each friend’s id to ids: We’ve been there before. I’m really notsure right now where we are. (~Ah, here)”. At some other point he says about acomplicated if statement: “I find it all quite confusing as well. I always make myselfa sketch each time to understand it (~at all).” (explain_standard of knowledge+explain_knowledge)
14.1.2 RT: Refusing knowledge transfer
The speaker negatively answers a query for information (ask_knowledge) or fora proposal (e.g. ask_step) by stating that he lacks the necessary knowledge forfulfilling the request. For example in Session CA2, C5 asks what argument topass to a method parameter: “That needs All, probably?”. C2 replies “No ideawhat that thing does”.
14.1.3 AT: Acknowledging knowledge transfer
The speaker states whether or to what degree a previous knowledge transfer(explain_knowledge or explain_finding) was successful or what its result was. Forexample in Session CA2, after C5’s explanation of the reasons for some changeshe had made, C2 states “OK, I don’t get it, but OK. I haven’t understood, butOK” to acknowledge the knowledge transfer as unsuccessful, yet terminate theepisode nevertheless. Elsewhere in CA2, C5 explains where to find a certainclass: “The VirtualAttribute is here in pro <*points on screen*>”, which C2first repeats, sounding astonished, then acknowledges as understood: “In<*packagename*>.pro is the VirtualAttribute? OK”. Type AT includes the casethat the speaker states to have possessed the respective knowledge even beforethe transfer.
14.2. standard of knowledge concepts and their properties 141
14.2 standard of knowledge concepts and their properties
As shown in Figure 3.2, we have observed ask_standard of knowledge and explain_standard of knowledge.
14.2.1 ask_standard of knowledge
The speaker sometimes queries the partner regarding how much he or sheknows about something. If the immediate goal of such questions is moreobtaining an understanding of the constraints under which the session isperformed rather than obtaining knowledge for directly pursuing the session’sgoals, then we encode them as ask_standard of knowledge.
For example in Session BA1, driver B1 wants to know how well his partnerunderstands the PHP script next to be reworked: “You don’t know the script atall, do you?”. Interestingly, B2’s reply is more complex than expected: “Yes, Ilooked at it a little while ago and it’s not actually complicated” (explain_standard ofknowledge+explain_knowledge). (To understand why explain_knowledge appearsas well, see Section 16.2.1.)
14.2.2 AT with paraphrasing
In order to state and make sure that transferred knowledge has properly beenreceived and understood, the speaker will sometimes paraphrase the knowl-edge in his or her own words, sometimes adding aspects that were not explicitbefore (sometimes even completing a cut-off or trailed-off utterance of thepartner); see Example 14.1 (5+6). Such utterances are still considered purelyexplain_standard of knowledge.
Example 14.1: Episode from Session BA1 (14:14:31–14:14:51) in whichexplained knowledge is paraphrased by extension to signal understand-ing.
(1) B2.ask_knowledge
“Can timestamp_last_change greater zero happen? (.) Er, er, less thanzero, or equals zero for all I care. (.) Under this <*points to screen*> condi-tion.”B2 asks about the value of a variable.
(2) B1.explain_knowledge
“Hmmm, that is our requirement so to say that we have of this function(!!...!!)”
B1 starts to answer but gets interrupted.
142 Chapter 14. Universal concepts: standard of knowledge
(3) B2.mumble_sth
“Should we not that there, so that not that there, I mean (!...!)”
B2 does not finish; it remains unclear what he intends to say.
(4) B1.explain_knowledge
“. . . that it returns zero, em.”
B1 ignores the interjection and continues his explanation.
(5) B2.agree_knowledge
“OK, hmhm.”
B2 agrees immediately.
(6) B2.explain_standard of knowledge
“If it doesn’t, if it fails, somehow.”
B2 complements B1’s explanation by a condition for the zero return. B1knows that condition but had not mentioned it. B2’s utterance states howhe understood the explanation and what he assumes to know now.
(7) B1.agree_knowledge
“Exactly.”
This confirms the correctness of the standard of knowledge that B2 claimsto have achieved, not the knowledge content, so it should be somethinglike attest_standard of knowledge, but we have decided against such a super-specialized and rare concept, using the much more generic agree_knowledgeinstead.
Note that paraphrasing of recently transferred knowledge also occurs as partof proposals and should then not be annotated as explain_standard of knowledge.See Example 9.2 where both uses of paraphrasing occur right after one anotherin utterances (2) and (3).
14.2.3 standard of knowledge in the making
We have discussed for finding (in Section 12.2.3) that sometimes speakers ver-balize some of the thinking process that leads to a finding before the findingitself.
Something similar may happen before a speaker diagnoses his or her standardof knowledge, as in this long utterance of B1 in Session BA1: “Really great wouldbe, if we could return something that always (!...!) (..) hm (...) Wait-a-sec. That
14.2. standard of knowledge concepts and their properties 143
always (!...!) (.....) Now I (~somehow) lost the thread.” Such utterances should beannotated with explain_standard of knowledge.
14.2.4 explain_standard of knowledge may be findings
A explain_standard of knowledge utterance may result from a fresh insight: afinding. Because of the priority rules stated in Section 11.3, it is neverthelesssimply annotated as explain_standard of knowledge. This is particularly andundoubtedly true if the utterance does not actually explain the finding but onlyannounces it, as in “I have an idea” from CA2.
14.2.5 Limited-knowledge proposals
As we have discussed in the respective chapters on the product-oriented andprocess-oriented concepts, a proposal is still a proposal if the speaker revealsthat he or she is not fully convinced of the proposal.
However, the base layer’s principle of encoding primary intentions (Sec-tion 2.3.2) demands that if the speaker apparently intends to inform the partnerabout a low or high standard of knowledge that underlay the proposal, thisshould be annotated separately as explain_standard of knowledge. However,minor doubts are common and so this rule would lead to frequent doubleannotations if applied generally. Therefore, we apply it only if the standard ofknowledge is expressed explicitly and separately – as in utterances (3)+(4) ofExample 9.3 taken together.
14.2.6 Implicit statements
Sometimes the standard of knowledge is not described explicitly and ratheran interest in certain information is stated instead. Examples: “I’d be interestedin that myself” (C2 in CA2, explain_standard of knowledge) or “I would like tounderstand it!” (B1 in BA1, explain_standard of knowledge and propose_step, B1starts investigating the respective source code right away).
14.2.7 Backward-looking statements
explain_standard of knowledge utterances are not always about the present, theymay also pertain to the past and sometimes even exclusively to the past (thatis, the standard of knowledge has since improved).
For instance in Session CA2, after deleting a line of code C2 remarks “Hadn’tunderstood it anyway” to declare a previous (and now irrelevant) lack of under-standing of the meaning of the deleted code line.
144 Chapter 14. Universal concepts: standard of knowledge
14.2.8 Signaling ongoing thinking
If a speaker reveals that he or she is currently thinking about something, thisshould be annotated with explain_standard of knowledge.
For example in Session BA1, B1 explains the consequence of a previouslyproposed change as “Ehm, that would make it optional” to which B2 replies“That’s what I’m considering”.
14.3 Discrimination from similar concepts
We discuss various discriminations of only the concept explain_standard ofknowledge to concepts from the finding and hypothesis and the product-orientedand process-oriented concept classes. With one exception, the discriminationfrom knowledge concepts however will be discussed in Chapter 16.
14.3.1 explain_standard of knowledge vs. ask_knowledge
Any explain_standard of knowledge that diagnoses a less-than-perfect knowledgelevel can also be interpreted as a request to transfer the missing knowledge:ask_knowledge. So what should we annotate? Relying on the priority rules(Section 11.3), we would always chose explain_standard of knowledge, because itis more specific. But another general rule should in fact take precedence here:The encoding of primary intentions (Section 2.3.2).
If the primary goal of the utterance appears to be obtaining knowledge bymaking the partner explain it, ask_knowledge is the right concept. But if theprimary goal is to simply inform the partner of the speaker’s knowledge-related situation, we use explain_standard of knowledge. Both concepts will beused together only if we find both goal types to be equally strong, which oughtto be rare.
14.3.2 explain_standard of knowledge vs. agree_finding or disagree_finding
Any agree_finding can be interpreted as an explain_standard of knowledge, butbased on the principle of encoding intra-dialog relationships (Section 2.3.6), theformer should take precedence to make the episode structure more visible; seeExample 12.5. This does not preclude an additional annotation with explain_standard of knowledge if sufficient emphasis of this aspect is present in theutterance nor an exclusive annotation with explain_standard of knowledge if theutterance is neither agreement nor disagreement but rather a statement ofinsufficient judgment capability.
The same holds for disagree_finding.
14.3. Discrimination from similar concepts 145
14.3.3 explain_standard of knowledge vs. explain_finding
See Section 14.2.4.
14.3.4 explain_standard of knowledge vs. agree/disagree for aproposal
We discussed in Section 14.2.5 that a proposal may lack complete conviction andsaid that such cases may or may not deserve additional annotation with explain_standard of knowledge. The same idea holds for agree and disagree utterances(regarding proposals) that reveal a sufficiently unreliable underlying standardof knowledge.
14.3.5 explain_standard of knowledge vs. propose_hypothesis
Formulating a statement as a hypothesis always also provides a glimpse of thecurrent standard of knowledge – do not let this fool you. Normally, the priorityrules (Section 11.3) suggest that in such cases propose_hypothesis, being the morespecific concept, should take annotation precedence; see most of the examplesin Chapter 13.
For understanding the overall session, though, it might actually be most produc-tive to consider the specific nature and origin of the ambiguity in a particularcase. For example, in the statement “Maybe I have even written some myself, I’mnot sure” the first part is clearly propose_hypothesis while the second part couldbe considered explain_standard of knowledge. However, you might come to theconclusion that in this particular case it is merely a re-emphasis of the “Maybe”at the front.
In other cases, the principle of encoding primary intentions (Section 2.3.2)might suggest otherwise and should then be given priority: If signaling theinsecurity appears more important than the actual content of the hypothesis,explain_standard of knowledge should (also) be used.
Chapter 15Universal concepts: gap inknowledge
15.1 Topic of gap in knowledge concepts
During our research, we found several cases where it appeared that momentsin which the pair recognizes (and states) that both partners are lacking the samerelevant piece of knowledge may be of particular importance for the furthercourse of the session. We decided to create a separate concept class for thisspecial case of standard of knowledge, called gap in knowledge.
For example in Session ZB7, driver Z20 summarizes the joint standard ofknowledge as “We don’t know whether our changes to the file (..) make it through toJBoss” (explain_gap in knowledge) and the observer confirms: “Exactly” (agree_gapin knowledge). This is one of the two types of explain_gap in knowledge utterancewe have seen: the situation summary, where the underlying knowledge deficitshave already been verbalized before and the utterance mainly puts them in anutshell.
The other type is asymmetric: The partner has (explicitly or possibly implicitly)declared a certain standard of knowledge and the speaker now declares hisown by way of explaining a joint gap in knowledge. Here is an example of the’implicit’ subtype from Session ZB7: Z20 summarizes the previous discussion(about how to obtain a Topic object) as
“The question is: Who provides us with a Topic? <*Z19: JBoss!*> JBoss,yes. JBoss provides it. Why does it do that? In which (.) file is it stated?And is that file generated by XDoclet or not?”
(ask_knowledge, or more precisely: Z20.ask_knowledge, Z19.explain_knowledge,
147
148 Chapter 15. Universal concepts: gap in knowledge
Z20.agree_knowledge, Z20.ask_knowledge). The pair looks at one another silentlyfor about 3 seconds before Z19 states
“Very good question. Can’t remember anything.”
(explain_gap in knowledge), which declares the joint technology knowledge ofthe pair to be too low.
15.2 gap in knowledge concepts and their properties
As shown in Figure 3.2, we have observed only explain_gap in knowledge andagree_gap in knowledge, but obviously at least the respective disagree, challenge,and amend concepts can readily be added as soon as a corresponding utteranceis encountered.
15.2.1 explain_gap in knowledge
The base layer requires for an explain_gap in knowledge phenomenon that thespeaker not merely diagnoses a gap in joint knowledge but also apparentlyassumes that this gap is considerably relevant for the further course of thesession.
15.3 Discrimination from similar concepts
We only discuss discrimination from standard of knowledge here (and frompropose_step) but postpone discrimination from knowledge to the respectiveChapter 16.
15.3.1 explain_gap in knowledge vs. explain_standard of knowledge
Most explain_gap in knowledge utterances can be considered to also fulfill theconditions for a explain_standard of knowledge. According to the priority rules(Section 11.3), only explain_gap in knowledge should be used and explain_standardof knowledge should not be used in such cases.
Specialized studies may for instance want to vary the ’speaker assumes rel-evance’ condition mentioned in Section 15.2.1 such that the gap must alsoobjectively be considerably relevant. Such studies will also need to make thenotion of ’considerable relevance’ more concrete.
15.3.2 agree_gap in knowledge vs. agree_standard of knowledge
According to the principle of encoding intra-dialog relationships (Section 2.3.6),agreements to a previous explain_gap in knowledge will always be annotated
15.3. Discrimination from similar concepts 149
with agree_gap in knowledge, never with agree_standard of knowledge, even if thespeaker only talks of him or herself.
If for an agreement to a previous explain_standard of knowledge you feel temptedto use agree_gap in knowledge because the speaker extends the previous ut-terance’s scope from the partner to the pair, then explain_gap in knowledge isprobably the right annotation instead.
15.3.3 explain_gap in knowledge vs. propose_step
An utterance such as “Now we need to find out: (.) Where does that value comefrom?” (BA1) will usually be a clear propose_step. However, if (as in this case)it can appropriately be paraphrased as “We should take time to think because weboth do not know where the value comes from” and recognizing that “both do notknow” is a relevant insight, then explain_gap in knowledge should be annotatedin addition. Such paraphrasing is often helpful for finding the right annotation.
Chapter 16Universal concepts: knowledge
16.1 Topic of knowledge concepts
Now would be a fine time to re-read Section 3.6, which introduced the notionof ’knowledge’ used in the base concept set, and Chapter 11.2, which explainsit in some more detail. We repeat the key points here:
• knowledge concepts represent verbalizations of (some forms of) knowl-edge, not the knowledge itself and also not implicit forms of knowledgetransfer.
• Most kinds of knowledge verbalization are addressed by other, morespecialized concept classes (such as finding or standard of knowledge), notthe knowledge class.
• The knowledge concept class serves as a kind of catch-all last resort, muchlike an else-clause, to accommodate utterances not captured by the otherconcept classes1 (Section 11.3).
• knowledge utterances are truthful (the speakers believe them to be true)but not necessarily true.
The latter two conditions result in a large variety of phenomena being rep-resented as knowledge in the base concept set. For instance the knowledgeunderlying a knowledge utterance may stem from a variety of areas, such as
• generic programming knowledge (such as design knowledge or technol-ogy details knowledge),
1Not all utterances: activity utterances remain.
151
152 Chapter 16. Universal concepts: knowledge
• domain knowledge (problem domain),
• product-oriented project knowledge about properties of the programsystem being developed,
• process-oriented project knowledge about previous events, activities,and decisions regarding the development process not covered by P&Pconcepts,
• and others.
Also, there are various different roles of knowledge utterances (see again Sec-tion 2.3.2 on illocutionary acts and Section 2.3.2 on encoding primary intentions)and correspondingly different types of knowledge could be discriminated.Most prominently, many knowledge utterances explain the reasoning under-lying a proposal and hence serve to justify the proposal. Such justificationscould have been expressed by a verb justify, so that for instance propose_designwould often be followed by a justify_design of the same speaker. Or considerthe following scene from Session CA2: Driver C2 throws his arms in the airand exclaims “I didn’t write that!”. This is clearly a rejection of responsibility,which we could have considered important enough a phenomenon to allocatea separate concept class for it. But as has been discussed in Sections 3.6, 3.7,4.2.3, and other spots, the base layer takes a different approach: It prescribesto simply use the generic (and somewhat vague) explain_knowledge in thosecases2.
In order to keep the size of the base concept set at bay, we also do not performthe area-based discriminations mentioned above or any other type of subcat-egorization and simply use knowledge for all of the variants. Since knowledgeis an important concept class, this means that future studies will add theirown concepts particularly often in this region, but note that it might be moreconvenient to add property concepts rather than splitting existing conceptclasses; see Chapter 22 for the discussion.
Example 16.1: Isolated (or mini-episode) examples of ask_knowledge andexplain_knowledge utterances, all from Session BA1.
(a) B2.ask_knowledge
“But curl is on it?”Question whether the http utility program curl is installed on the develop-ment machine.
2And also for other types of justifications such as the “I didn’t write that!” that C5 claims withdefensively lifted hands in CA2 after C2 criticized some code and which could have been expressedwith a concept such as explain_responsibility
16.2. knowledge concepts and their properties 153
(b) B1.explain_knowledge
“Yes.”Answer to question (a).
(c) B1.explain_knowledge
“Well, we don’t call that. It has such a big overhead that I have left it out.Look, it’s commented out up here.”
B1 answers a question regarding the use of some existing functionality. Thestatement soon after turns out to be not entirely correct.
(d) B2.ask_knowledge
“What do you do here? Here you check, er, whether, er, id_code is a realkey, real thingamabob?”
A question while displaying a particular piece of code.
(e) B1.explain_knowledge
“Ahm, right. (.) That’s simply hex with 16 (.) digits.”
Answer to question (d).
(f) B1.explain_knowledge
“friends_ids. (.) There we have it; that’s why it did it. Writing com-ments razzes me. i d s and ids are easily confused, id_codes you can’tconfuse. And that function here <*highlights a call*> is called id_to_code
anyway.”
Without having been asked, B1 explains names he has chosen prior to thesession.
16.2 knowledge concepts and their properties
As shown in Figure 3.2, we have observed explain_knowledge, agree_knowledge,disagree_knowledge, challenge_knowledge, and ask_knowledge.
16.2.1 Evaluations and judgments
Most evaluations or judgments of artifacts, parts or aspects of artifacts, orother items such as conventions are findings and require a finding concept.Sometimes, however, the speaker reveals that the respective insight is notrecent and then explain_knowledge ought to be used instead; the final PToexample in Section 14.1.1 is such a case.
154 Chapter 16. Universal concepts: knowledge
16.2.2 Unprompted knowledge transfer
Speakers sometimes explain_knowledge without prior query from the partner,as in Example 16.1 (f). Although this will often appear to be triggered by aninsight (“My partner needs this knowledge now.”), no finding concept is annotatedunless the insight is verbalized; usually, only explain_knowledge will be used.
16.2.3 Rhetorical questions
Presumably-rhetorical questions for knowledge will not usually be annotatedas ask_knowledge. Rather, their illocutionary act needs to be determined: Theymay be the verbalization of an insight or knowledge (as in the DO example inSection 12.1.5), lead-in to such verbalization, or implicit suggestions what towork on (then use propose_step, see Example 12.2 (3)).
16.2.4 Aggregation of utterances
The same rules apply as discussed for finding in Section 12.2.1; see Example 16.1(c) and (f).
16.2.5 amend_knowledge?
In contrast to findings, which are held together reasonably well by the shortperiod in which the insight was achieved (but note our nevertheless simplifiedhandling of amend_finding in Section 12.2.5), it is very difficult to determine asensible granularity that defines what is considered one piece of knowledgeversus another (in particular because knowledge contains so many differentthings that are not clearly kept apart). It would therefore be overly difficultto provide a consistent operationalization of amend_knowledge (in contrast tojust using another explain_knowledge) and we have thus not included amend_knowledge in the base concept set.
16.2.6 “Different” answers
Not every question is answered in the manner expected by the asker. Forinstance, the reply may instead explain why an answer is not actually neededas in Example 16.2. Such phenomena are not particularly frequent and are notaddressed explicitly in the base concept set; we simply use explain_knowledgehere as well.
Example 16.2: Episode from Session CA2 (12:04:53–12:05:13) in whichthere is a difference of opinion regarding a knowledge transfer.
(1) C5.ask_knowledge/C5.propose_step
“Do you know the (.) how I access the function to change a method?”
16.2. knowledge concepts and their properties 155
Said while opening the context menu for method setVirtualAttributes.Section 6.3.3 discusses this double annotation.
(2) C2.explain_knowledge/C2.disagree_step
“That doesn’t get you anywhere.”
C2 answers by giving an assessment of the idea underlying the question.Section 6.3.6 discusses this double annotation.
(3) C5.challenge_knowledge+C5.propose_design
“It does. In the method, once opened, I can turn the IVirtualColumn intoI(!!...!!)”
C5 insists on his idea, explaining his immediate goal. C2 interrupts him.
(4) C2.challenge_knowledge/C2.disagree_step/C2.disagree_de-sign+C2.explain_knowledge
“That will (!...!) That doesn’t buy you much. But Alt-Shift-C, do, do itwith Alt-Shift-C.”
C2 dissents again, but suggests an approach we decided to be the answerto the original question.
(5) C5.challenge_knowledge
“Alt-Shift-C should be constants.”
The driver explains that the key combination will call some other than therequired functionality.
16.2.7 Modes of agreement
An agree_knowledge utterance can be made in at least the following three differ-ent modes:
• known: The recipient knew this before, as in Example 12.2.
• understood: The recipient signals to have understood the explanationand to consider it correct, whether after an actual verification or otherwise.See Examples 14.1 and 16.3 (4). Such utterances often border on explain_standard of knowledge; see Section 16.3.10.
• unchecked: The recipient signals to be willing to assume the explanationto be correct without making his or her own judgment about it. SeeExample 16.4 (1). Such utterances often have the character of pushingaway additional explanations or of delegating responsibility (see alsoExample 16.3 (6)) or they are preliminary.
156 Chapter 16. Universal concepts: knowledge
We consider these modes to form different agreement types here, that is, prop-erties that characterize agreement utterances; compare to the respective typesfor agree_finding (and their role) in Section 12.2.9.
Example 16.3: Episode from Session CA2 in which the partner correctsexplained knowledge.
(1) C5.propose_design
“As it is now (;) we can do without this one.”
The driver highlights one line of code and suggests deleting it.
(2) C2.explain_knowledge+C2.agree_design
“That wasn’t right anyway.”
The observer agrees and states the logic in that line to be incorrect.
(3) C5.challenge_knowledge
“It was right before. It was no longer after your change. Before it it was.”
The driver dissents and explains when the line had become wrong (whichwas before the session).
(4) C2.agree_knowledge+C2.disagree_knowledge
“Uhuh, OK. (..) Actually not.”
C2 agrees, then reconsiders and disagrees.
(5) C5.explain_knowledge
“That was (!...!) The, the, the strategy then was such that via (.), er,AllColumnAttributes we’d get the virtual ones as well. So I had to resetthem and upon no change set them again.”
C5 elaborates further.
(6) C2.explain_standard of knowledge
“(OK, I don’t get it, but OK.) I haven’t understood, but OK.”
C2 gives up his attempt to understand and pushes off further explanations.
Example 16.4: Episode from Session CA2 (12:05:16–12:05:35) whichfollows directly after Example 16.2.
(1) C2.agree_knowledge
“Okayyy”
16.2. knowledge concepts and their properties 157
The observer agrees (using mode unchecked) to the challenge_knowledge ofExample 16.2 (5).
(2) C2.explain_finding
“Then you have changed that.”
C2 now recognizes (a TC-type finding) that C5 must have modified theAlt-Shift-C key binding.
(3) C5.amend_finding
“’t is <**developer name**>. And we have the (.) agreement here, y’ know,that we’ve set it so.”Although it comes from existing knowledge and although it justifies, thisutterance is amending the finding.
(4) C2.agree_finding+C2.explain_knowledge
“Yes, sure, well, who, who likes it, who likes to change it, sure.”
C2 agrees to the amendment and then evaluates its content which the baselayer treats as explaining existing knowledge.
(5) C2.agree_step/C2.explain_knowledge
“Then do (!...!). You need to point here <*points to method name*> (..)then ’refactor’, ’change method signature’.”
C2 answers the question from Example 16.2 (1), agreeing to the step byexplaining how to perform it.
16.2.8 Indicating agreement vs. indicating attentiveness
See Section 4.2.7.
16.2.9 Opposition and controversy
As for most base concept classes, explained knowledge can be contradicted intwo manners:
• challenge_knowledge: The explanation is refused in a manner that providesadditional knowledge which either subjectively corrects the knowledge asin Example 16.3 (3) or which at least shows that the previous explanationcannot be correct as in Example 16.2 (5). For the latter case, later studiesmay decide that it would be better to annotate disagree_knowledge+explain_knowledge rather than challenge_knowledge.
158 Chapter 16. Universal concepts: knowledge
• disagree_knowledge: The explanation is refused without providing ad-ditional knowledge, as in Example 16.3 (4). Such utterances are oftenshort.
16.2.10 Disagreeing by agreeing to the opposite
If an explain_knowledge states a binary property, e.g. “X does not have propertyY” and the partner disagrees in “Yes, it does!”-style, this should be consideredoffering alternative knowledge and thus be annotated with challenge_knowledge.
16.2.11 Opinions
The base concepts considers an utterance expressing an opinion to express abelief. It should therefore be annotated with explain_knowledge.
16.2.12 Limited conviction
While an explain_knowledge is always uttered with apparently complete convic-tion (otherwise it would be propose_hypothesis instead), the base concepts donot require complete conviction for subsequent agree and disagree utterances,which explicitly or implicitly are allowed to reveal remaining doubt; see Exam-ple 9.3 (8). The example “Really?” from BA1 illustrates that this even resultsin cases where it is difficult to decide between annotating agree_knowledge andannotating disagree_knowledge.
16.2.13 ask_knowledge is not always that
Many explain_knowledge utterances are triggered by a previous question, as inExample 12.2 (4), see also (6). But such questions are to be annotated as ask_knowledge only if they do not imply a proposal, as Example 12.2 (3) does, andalso do not pertain to P&P concepts.
16.2.14 Questions including possible answers
Speakers sometimes phrase questions that include a hypothesis for the answer,such as Example 16.1 (4). If such a hypothesis appears to be present merelyfor clarity or other rhetorical purposes, we simply annotate ask_knowledge. Apropose_hypothesis is added only if the hypothesis appears to be meant as such(perhaps as the primary aspect then); see Section 16.3.6.
16.2.15 Statement or question?
Even when fully exploiting the information available from context and intona-tion, it is sometimes hard to decide whether an utterance should be taken as astatement for explaining knowledge (explain_knowledge) or as a question asking
16.3. Discrimination from similar concepts 159
for verification (ask_knowledge). It may even be that neither is the case and thespeaker is actually formulating an insight to be exploited (explain_finding).
The best example we have is untranslatable into English because it rests on theuse of the German word “ja” (normally “yes”) as a modal particle. With thatword left in, the half-translated utterance of C2 from Session CA2 goes
“The processing of the, the thread IDs stays [ja] the same, there is [ja]nothing (!...!)”
C2 says this unpromptedly after he stated the pair could now proceed (after asuccessful test). C5 replies “Exactly”. The “ja” can mean “as you know”, whichwould lead to the meaning explain_knowledge. Or it can mean “I think”, whichwould allow for ask_knowledge or explain_finding. Or it can mean “surprisingly”,which would suggest explain_finding. The nature of knowledge as the fallbackconcept class suggests to annotate such ambiguous cases as explain_knowledge.
16.3 Discrimination from similar concepts
Except for a very few bits and pieces, everything needed to correctly applythe knowledge concept class and to discriminate its instances from those ofthe previous classes has been said above. But because of the importance ofknowledge utterances and the subtlety of the class (due to its catch-all character),we nevertheless discuss a large number of cases explicitly at least shortly here.
16.3.1 explain_knowledge vs. propose_step
A longer utterance containing a step proposal can involve three aspects: Theactual step proposed, a justification of why it should be performed, and anadditional explanation of how it could or should be performed. Only the first ofthese is annotated as propose_step, the other two parts, if present, must each beannotated with an appropriate knowledge, finding, or perhaps hypothesis concept.Without a separate proposal, the otherwise exact same explanation how to do“it” can be considered the proposal.
16.3.2 explain_knowledge vs. propose_design
If design proposals are accompanied by a separate justification, separatelyannotate the latter as explain_knowledge as discussed in Sections 3.7 and 4.2.3:propose_design+explain_knowledge. If the proposal is implicit in the knowledgeutterance, use a double annotation propose_design/explain_knowledge; see thediscussion in Section 4.3.2.
160 Chapter 16. Universal concepts: knowledge
16.3.3 explain_knowledge vs. explain_finding
As we have discussed at length in Chapter 12, we use finding not only forutterances that contain findings explicitly, but in many other cases as well. Fiveremarks remain to be made:
1. If finding and knowledge appear equally likely, then explain_knowledge shouldbe used: we may lack any symptom at all that would let us favor findingover knowledge or vice versa, as in the following example from BA1 whereB1 asks “What will happen here when this friend here deletes himself <*points to apaper note*>? (.....) Then strictly speaking I have to, then strictly speaking I need to(~invalidate) mine, my friends list.” and B2 answers without any hesitation
“That it does, yes. It, you are friend (~too) of him who deletes himself. (.)And here in this function will be (.) for all (.) of his friends, including you,(.) the MemCache object will be (~deleted).”
You may perceive the promptness of the reply to suggest existing knowledgeas the content of the reply, but it may as well be a finding created duringthe five seconds of silence within the previous utterance of B1. We simplycannot decide the matter and will annotate explain_knowledge as a result. Suchproblems are common in particular for (possible) findings of the idea types (TCand even more so TU).
2. Even if a linguistic finding symptom such as “Ah, ...” is present in theutterance, it may only signal an insight of the type “I just recognize that youneed the following information”, but the base layer does not annotate such minoraspects of utterances. If the content of the subsequent utterance is existingknowledge, the whole utterance should be annotated with explain_knowledgeand only with explain_knowledge.
3. It is normal that existing knowledge is required for having an insight. Itis therefore also normal that such existing knowledge is verbalized as partof the verbalization of the insight. Such verbalizations should normally beannotated simply as finding, except if the speaker explicitly marks some partof it as existing knowledge, in which case a separate annotation or doubleannotation of explain_knowledge is called for.
4. Explaining existing knowledge may itself be the trigger for an insight – apotentially very important phenomenon for understanding pair programming.If this happens, both parts should separately be annotated accordingly as afterthe self-interruption in the following B1 utterance from Session CA2:
“The problem is, er, if you want to, er, use the (.) Columns, and in all
too, you need to have the same attribute column (.) names. And to havethat, you need to (!...!) Oh, no, stop, that’s not a problem: We have themhere.”
16.3. Discrimination from similar concepts 161
5. The speaker’s idea that existing knowledge should be explained will often bea finding. If this idea itself is not verbalized, however, the base layer suggeststo annotate explain_knowledge only. Since the idea may be important for thesession, subsequent studies may decide to change this decision.
Many of these remarks apply not merely to explain_knowledge and explain_finding, but likewise to amend_finding, challenge_finding, and challenge_knowledge.
16.3.4 explain_knowledge vs. amend_finding, challenge_finding,disagree_finding
Elaborations as part of explain_finding as well as parts or all of amend_finding orchallenge_finding utterances may consist of existing knowledge. In the base layer,this fact is not annotated; according to the episode principle (Example 2.3.6),only the respective finding concept is used. Later studies may want to introduceproperties to be annotated additionally in order not to lose the informationabout the origin of the knowledge in such cases.
Accordingly, a disagree_finding elaborated by a justification based on existingknowledge will be annotated as challenge_finding.
16.3.5 explain_knowledge vs. agree_design/disagree_design
Rather than to agree or disagree with a design proposal explicitly, the speakermay package his opinion in a knowledge utterance. As this may be a relevantphenomenon for pair programming, the base layer suggests to use doubleannotations (e.g. disagree_design/explain_knowledge) in such cases.
The same idea applies to all P&P proposals, but in our data we have observedsuch behavior only for design.
16.3.6 ask_knowledge vs. propose_hypothesis
We have previously allowed that a hypothesis utterance may take the form of aquestion (as in the example below). We have also allowed that an ask utterancemay include possible answers (as in Example 16.1 (4)). Therefore, there maybe ambiguity whether an utterance is asking for knowledge or proposing ahypothesis. The base layer rule for these cases states to use ask_knowledge iff itappears that the speaker believes the partner will be able to reliably answer thequestion (and use propose_hypothesis otherwise).
Here is an example from BA1: After the pair changed an argument suppliedto a PHP script, the observer wonders what the result will now be: “Is greater.(~So we) should get an exit, not a (~friends list), or not?” Here it is unlikely thatthe speaker assumes definite knowledge in his partner, in particular since that
162 Chapter 16. Universal concepts: knowledge
partner had attempted (and aborted) an explanation himself previously, sopropose_hypothesis is the right annotation.
In contrast in Example 16.1 (4), while the second part sounds a lot like propose_hypothesis, the first part is a direct question to the partner, so ask_knowledgeit must be. Example 16.5 is another illustration for how similar these twoconcepts can be.
Example 16.5: Episode from Session CA2 (12:29:04–12:29:10) showingthe similarity of ask_knowledge and propose_hypothesis.
(1) C2.ask_knowledge
“That’s how it went, with a minus, right?”
The pair is filling an SVN commit message and wonders about the pre-scribed syntax for the task ID. C2 has typed ’cad-509’ and has moved thecursor back to the minus sign.
(2) C5.propose_hypothesis
“I think the ’cad’ is upcased or so?”
As C2 is apparently unsure about the format, C5’s question must be a hy-pothesis.
16.3.7 ask_knowledge vs. explain_finding
Questions are typically the result of a more-or-less recent insight which toldthe speaker that he or she is lacking relevant information or understanding.Such a tacit underlying insight is not annotated unless the question must beconsidered rhetorical in which case the question is not annotated as such. Aborderline case occurred in Session BA1, where the driver encounters tabulatorcharacters in the source code and asks “What are these TABs here?”. explain_finding and ask_knowledge are equally adequate annotations for this utterance,see Example 12.4 for the context.
16.3.8 explain_knowledge vs. explain_standard of knowledge
As discussed in Section 14.2.2, if a speaker paraphrases knowledge previouslyexplained by the partner, this will be annotated as explain_standard of knowledgeeven if it includes additional bits of knowledge as in Example 16.6 (2). Thisrule was chosen for practicality. Its limit is reached when the parts can clearlybe identified as separate instances in which case explain_knowledge should beused for the respective part. Later studies may wish to find more refined rulesin this area.
16.3. Discrimination from similar concepts 163
Example 16.6: Episode from Session CA2 (11:53:01–11:53:23) in whichC2 agrees to an explanation by means of explain_standard of knowledge.
(1) C5.explain_knowledge
“I said, I (...) I (.), er, work different from you. I (...) includingalong. I have included in the considerations that they from thatgetColumnAttributes may, that they are included there. That’s whythey’re reset there now.”
The observer “explains” the code he wrote before the session. He points tospots visible on the screen.
(2) C2.agree_knowledge+C2.explain_standard of knowledge
“Um, then you can easily, then you can easily change it. (!!That had con-fused me.!!)”
C2 agrees by explaining how he understood the explanation. C5 interruptshim during the last part.
(3) C5.explain_knowledge
“(!!Yes.!!)”
C5 states that C2 understood him correctly. (There is no specialized baseconcept for such utterances.)
16.3.9 ask_knowledge vs. explain_standard of knowledge
See Section 14.3.1.
16.3.10 agree_knowledge vs. explain_standard of knowledge
An agree_knowledge is sometimes ambiguous versus an AT-type explain_standardof knowledge. In such cases we stick to the episodes principle (Section 2.3.6) andannotate agree_knowledge unless both possible intentions are made somewhatexplicit, in which case we either make a double annotation as in Example 16.6 (2)or split up the utterance as in Example 14.1 (5+6).
Chapter 17Universal concepts: activity
17.1 The notion of facade concept class
The design pattern Facade1 [7] defines a construct (usually a class) that providesan appropriately simplified view of a set of other constructs (such as a set ofclasses), omitting detail and focussing attention on the parts relevant for thepurpose at hand.
The base layer borrows (rather loosely) from this idea to introduce the notionof a facade concept class. A facade concept class contains concepts that provide asimplified perspective on a part of a session. That part is
• somehow coherent for the purpose of the analysis,
• but consists of more than one utterance or of an utterance and somethingelse (and often both).
Such facade concepts will typically not be used alone: they are designed tocommonly be used as one part of a double annotation. The elements of anyone facade concept class together may or may not provide an episode structureas the normal HHI concept classes do.
In the base layer, activity is the only facade class, but others might conceivablybe introduced in later studies.
17.2 Topic of activity concepts
The activity concepts represent utterances that comment on HEI or HCI ac-tivities (Chapter 19) currently or recently going on, for instance expressing
1http://en.wikipedia.org/w/index.php?title=Facade_pattern&oldid=559454643
165
166 Chapter 17. Universal concepts: activity
agreement or disagreement with actual code changes just performed by thepartner. They thus link the HHI dialog world to the HCI/HEI world.
The core concept is think aloud_activity. Such utterances explain on the fly allor part of what the speaker is concurrently doing2. One think aloud_activityaddresses exactly one activity (but several think aloud_activity annotations maybe made for subsequent stretches of the same activity). The verbalization canbe descriptive. Or it is explanatory, reflecting, or otherwise adding (whetherconsciously or not) information beyond what the partner could derive by pureobservation otherwise. In particular, the verbalization may constitute one ormore instances of HHI concepts. These will be annotated separately and thethink aloud_activity serves to capture their relationship to one instance of anHCI/HEI concept. For example in Session CA2, C2 is modifying a method:
“<*starts modifying the method*>It ought to be implemented like this. (;;;)<*stops modifying the method*>(.)<*starts wandering up and down with the cursor*>And it must not, definitely not, be part of Abstract. Or so I think.<*stops wandering up and down with the cursor*>”
The activity being verbalized here is a write_sth (see Section 19.1), the two HHIutterances are both propose_design, and the think aloud_activity relates thosethree parts to one another.
Note the cursor wandering may in fact be a form of displacement activity4. Thebase layer’s model of HCI/HEI activities is coarse, so it provides no conceptsfor modeling such behavior, but subsequent studies may want to introduceappropriate extensions.
A think aloud_activity may start a bit before the activity or continue a bit afterits end as explained in Figure 17.1. In any case, the base layer suggests a newactivity always requires a new instance of think aloud_activity.
The concept does not say anything about what the content of the verbalizationis, how complete it is, or whether the resulting information or integration ofthe partner is a conscious goal or not. If the verbalization comes in severalparts with pauses in between, multiple instances of think aloud_activity may beused. These rules will be elaborated in Section 17.3.
A think aloud_activity utterance typically addresses one or more of the following:2 Starting to verbalize is typically a spontaneous decision of the speaker, so this concept is
different from what happens when using the think aloud research method3 where the speaker isrepeatedly requested to verbalize.
4http://en.wikipedia.org/w/index.php?title=Displacement_activity&oldid=
558153583#Use_in_science
17.2. Topic of activity concepts 167
time
verbalization
throughout
partial verbalizations
verbalizations
beginning before and
extending beyond
two adjacent activities
with separate
verbalizations
verbalization
extending into a
subsequent activity
HCI/HEI activity
think aloud_activity
Figure 17.1: How activities may relate to think aloud_activity utterances.
• TA1: What am I doing? This may include verbalizing typing input. Willoften involve propose_design.
• TA2: Why am I doing what I am (or soon will be) doing? Will often beexplain_knowledge (or finding).
• TA3: How am I doing what I am (or soon will be) doing? Will typicallybe explain_knowledge.
• TA4: What decisions am I making? Will often be propose_design or propose_step (but also amend and challenge and sometimes others).
• TA5: What decisions underlie my activity? Often involves a strategy.
• TA6: What fresh insights am I having? Will usually be finding utterances.
• TA7: How do I interpret and evaluate feedback the computer is provid-ing? Also finding.
• TA8: How sure am I to be doing the right thing? Tends to be explain_standard of knowledge.
• TA9: How do I judge the quality of what I am doing? Tends to be finding.
• TA10: How far have I come in what I am doing? Typically completion.
168 Chapter 17. Universal concepts: activity
• TA11: How does the infrastructure (development tools and runtime tools)influence what I am doing? Typically knowledge or finding.
Here are a number of examples from Session BA1. The mentioned HCI/HEIconcepts will be introduced in Chapter 19.
1. B1 modifies a URL in a shell script call and remarks on two differences tohis usual workstation setting. B2 makes an interjection and B1 replies withoutstopping the editing. Length 33 seconds:
“ <*start write_sth*><*TA11:*> I need to adjust each time to not having an apple-key. (;)<*TA4:*>Here. We simply use localhost, I’d say. (;;;;;) (And then it is)(!...!)<*B2: You call it from the shell, don’t you?*>Yes. (;) <*TA1: reads his inputs aloud*> projects, um, <**URL part**>(..) trunc (.) API (;;) <**URL part**> (~~)<*end write_sth*><*TA11:*>Mighty small, that screen.”
2. B1 has opened the Eclipse Preferences window and is expanding several treenodes. Length 3 seconds:
“<*do_sth is running*><*TA2:*> Hmmm. Fonts and Colors must be somewhere.<*do_sth continues*>”
3. A short time later Fonts and Colors is found. B1 wants to make the editorfont smaller to get better overview in the code. He eventually finds that hisCourier font size change to the smallest value 10 did not help much. Length 21seconds:
“<*do_sth is running*><*TA4:*> Let’s see. What does Courier have? (;;;;;;;;;;;;;) Bah! (;;)<*TA10:*> Not a big improvement.<*TA6:*> The problem is it cannot go much smaller.<*end do_sth*>”
4. Elsewhere, B1 opens a file by double-click, but it opens in the external editorTextPad rather than the internal Eclipse editor. Another attempt via the contextmenu has the same result. The third attempt uses a different context menuentry. Length 27 seconds:
17.3. activity concepts and their properties 169
“<*start do_sth*>(;;;) <*TA5:*> OK, we don’t do that with TextPad (;;) No way. (;;)<*TA6:*> We need to tell it with what to open it. (;;;)<*B2: Can’t you drag-and-drop? (~~)*>Oh God. (;)<*TA3:*> We need to use this: Open in Editor.<*do_sth continues*>”
5. Still elsewhere, B1 has changed a configuration file and once again callswget http://dev-intern in a shell. The call terminates with the message“connection refused”. Length 13 seconds:
“<*start verify_sth*>(;;;) <*TA4:*> Then we can try it again. (;;;;)<*TA7:*> OK, the connect still doesn’t like us. <*end verify_sth*>”
17.3 activity concepts and their properties
As shown in Figure 3.2, we have observed think aloud_activity, agree_activity,disagree_activity, challenge_activity, amend_activity, and stop_activity. While thinkaloud_activity refers to activity of the speaker, all others refer to activity of thepartner; see Section 17.3.14 for corner cases.
A joint goal for most of the rules for using these concepts, in particular thinkaloud_activity, is not to allow the granularity get too small. Subsequent studiesmay need to deviate from the rules wherever they blur the relevant phenomenatoo much, e.g. a study interested in the role of fluent versus halting speech.
17.3.1 Granularity of think aloud_activity
A core question for the activity class is to determine the beginning and endof a think aloud_activity. We answer it by answering a whole sequence ofsubquestions as follows.
• When do we consider an HCI/HEI activity to begin or end? This will bediscussed for each type of activity in Chapter 19. In short, the answer is to befound neither by looking at syntactical elements of the artifacts nor by lookingat contiguous stretches of physical activity but rather by considering logicalwork steps.
• How to handle verbalizations beginning before or ending after the HCI/HEIactivity (Figure 17.1)? If the protruding part is only a part of an utterance,it should usually be considered to be part of the think aloud_activity iff theutterances are comments going along with the activity. Such prefixes andsuffixes should be kept short, however. For instance in Example 5 above,
170 Chapter 17. Universal concepts: activity
the verify_sth could technically have been considered complete before the lastutterance, but for understanding it is more helpful to extend the think aloud_activity to fully include it.
• How many aspects relevant for the activity can be left unsaid before we stopcalling it a think aloud_activity? How many need to be verbalized at least? Thenumber is irrelevant; only one aspect needs to be verbalized.
• How continuous and contiguous does a verbalization need to be (gaps andpauses, Figure 17.1)? Arbitrary gaps and pauses are acceptable as long asthe same verbalization intent still appears to be at work. Only if the speakerappears to stop the verbalization entirely and then begins a new one will weannotate a new think aloud_activity. The behavioral details of this difference aredifficult to describe but are often not difficult to decide for an actual researcher.
• How to handle deviations from the main topic? As long as the deviationis semantically connected to the activity’s topic at all, the think aloud_activityis allowed to continue. For instance in Session BA1, there is a point duringan editing step where the actor explains a syntactic improvement to the PHPlanguage that he would like to see introduced.
• How to handle interjections from the partner? If the actor reacts to themcasually or not at all, they are not considered to break the think aloud_activity. Ifthe actor reacts to them by shifting her attention focus, the think aloud_activityends. Subsequent studies may wish to change either of these decisions.
17.3.2 think aloud_activity phenomena leading to questions
If the actor poses a question to the partner during a think aloud_activity andcontinues verbalizing right afterwards, the question is not considered to breakthe think aloud_activity. If there is a speaking pause after the question, the rulesfor gaps and pauses from Section 17.3.1 apply. Subsequent studies may wantto introduce their own rules for this aspect.
17.3.3 HCI/HEI activities resulting from an utterance
think aloud_activity represents utterances that accompany an HCI/HEI activity.In the converse case, an activity may accompany an utterance (most commonlypointing to or highlighting on the screen). think aloud_activity does not apply tosuch situations.
Subsequent studies for which such auxiliary activities are important shouldintroduce an appropriate class of facade concepts to express the relationship.An example might be a study interested in misunderstandings due to missingpointing and highlighting.
17.3. activity concepts and their properties 171
17.3.4 Disconnect of HCI/HEI activity and verbalization
If utterances of the actor during an activity have no discernible semantic rela-tionship to the activity, think aloud_activity is not applicable. If a think aloud_activity is already ongoing, the utterance(s) should be treated like pauses andgaps (Section 17.3.1).
Subsequent studies may want to introduce a new facade class for such phe-nomena if they occur regularly.
17.3.5 The partner commenting on activity vs. on verbalizations
Use agree_activity, disagree_activity, challenge_activity, amend_activity, and stop_activity when the partner comments on what the actor is doing. They do notapply if the partner only comments on the actor’s verbalization of what he orshe is doing.
Note that many activities have so little physical “body” that activity and ver-balization are hard to keep apart and so the above problem is less likely tooccur.
17.3.6 challenge_activity
The counter-proposal formulated in a challenge_activity may pertain to processaspects of the activity (procedure, as in Example 17.1), to product aspects(content, as in Example 17.2), or to both.
Example 17.1: Episode from Session BA1 (13:46:49–13:47:01) containinga procedure-related challenge_activity.
(1) B1.propose_hypothesis
“Ah, maybe we must enable the chat.”
B1 is already in an B1.explore_sth. This utterance starts a B1.think aloud_activity.
(2) B2.agree_hypothesis
“Um, or so.”
This does not break the B1.think aloud_activity.
(3) B1.propose_step
“That’s a possibility. We need the auto_prepend.”
This continues both the B1.explore_sth and the B1.think aloud_activity:B1 moves the Eclipse Navigator View’s highlight cursor to the fileauto_prepend. B1.explore_sth ends. B1.think aloud_activity ends.
172 Chapter 17. Universal concepts: activity
(4) B2.challenge_step
“No, that’s in the Conf.”
This constitutes a B2.challenge_activity.
(5) B1.propose_step
“I’ll first make a Working Set.”
B1 calls the Eclipse function Select Working Set (B1.do_sth and B1.thinkaloud_activity).
Example 17.2: Episode from Session BA1 (14:30:39–14:30:47) containinga product-related challenge_activity.
(1) B2.propose_design+B2.explain_completion
“return 0, but otherwise; exactly.”
B1 is modifying a return statement (B1.write_sth). B2 proposes somethingabout its content (B2.amend_activity), B1 continues editing, B2 finds hisproposal to be implemented (B2.agree_activity).
(2) B2.propose_design
“No, that was quite right.”
B1 selects a part of the return statement do delete it (B1.write_sth contin-ued), B2 requests to leave it as is (B2.challenge_activity).
(3) B2.explain_standard of knowledge
“Aaah, you want to do it up there.”
B1 performs the deletion (B1.write_sth continued), B2 recognizes his plan ofaction and agrees with it (B2.agree_activity).
17.3.7 agree_activity, disagree_activity
Activity agreements are often very short utterances. See both a long and a shortone in Example 17.2.
Activity refusals that come without a counter-proposal (disagree_activity) areoften very short utterances and just like challenge_activity may pertain to processaspects or product aspects. For instance in CA2 the driver is about to click’Commit All’ in an SVN commit operation when the observer says “Not All”.
17.3. activity concepts and their properties 173
17.3.8 Comments before the fact
The disagreement in the above example was uttered before the deed it referredto had actually begun. This was possible because the speaker could see thepreparations and infer the intention. Such behavior is possible for agree, disagree,challenge, amend, and even stop_activity.
17.3.9 Comments after the end
An agree, disagree, challenge, and amend may be uttered when the respectiveactivity has already terminated. Such annotations are acceptable if the gapis sufficiently short and there are other symptoms as well that suggest thecomment pertains to the activity itself (such as the act of searching) rather thanonly its result (such as the search hits found).
17.3.10 amend_activity vs. challenge_activity
When the partner comments on an activity constructively (that is in a proposal-like manner), it is not always easy to decide whether that includes an elementof criticism (challenge_activity) or not (amend_activity). Example 17.3 illustratessuch ambiguity.
The base layer suggests to use amend_activity whenever no controversy isapparent in the utterance itself nor in the partner’s reaction, and also useit when the actor had previously hesitated (and even if controversy ensuesafterward). Subsequent studies particularly interested in such phenomena,however, will need to develop their own, much finer set of rules here.
Example 17.3: Episode from Session CA2 with high ambiguity. The pairhas discussed how to modify a particular interface. The respective fileis open.
(1) C5.mumble_sth (semantics unclear)
“OK. (;;;;) That would be (!...!)”
The OK may signal a start of something (C5.think aloud_activity begins).C5 navigates to method setVirtualColumns in the Eclipse package explorerand hovers there (C5.explore_sth).
(2) C2.propose_design
“getVirtualAttributes then maybe.”
C2 suggests what to modify. This should be C2.amend_activity if the re-searcher has not seen a different action plan in the activity of C5 andshould be C2.challenge_activity otherwise. C5 promptly starts editing themethod name (C5.write_sth).
174 Chapter 17. Universal concepts: activity
17.3.11 stop_activity
If a speaker disagrees with an activity that has already started but not yetended, and disagrees with the whole of it rather than only some aspect, wedo not use disagree_activity but rather the specialized stop_activity: An explicitappeal to entirely terminate the current activity.
For example in Session CA2, the driver is testing a class by means of the JDemoGUI testing framework, when observer C5 says “OK, but what we did has moreinfluence on the Action (.) than on (.) the GUI. So (.) that means, I’d rather go from<**application name**>.” This is an C5.explain_knowledge leading to a C5.propse_step, the latter constituting a stop_activity.
17.3.12 Interjections leading to activity change
Activity comments need not be stop_activity to lead to a change of activity.Example 17.3 may be such a case (but possibly the change would also havehappened without the interjection).
17.3.13 think aloud_activity by the “observer”
think aloud_activity requires actorship and so most commonly is performed bythe driver. In practice, however, the “observer” also may look something upin a book, make a sketch on paper, or do any of many other things that entitlehim or her to think aloud_activity as well.
17.3.14 Self-criticism
The verbalization occurring during an activity (think aloud_activity) may includeelements such as
• self-evaluations of the activity which have a positive result, reinforce theactivity, and would be annotated as agree_activity if they came from thepartner;
• self-evaluations with negative result that flag some aspect as deficientand would be annotated as disagree_activity if they came from the partner;
• self-evaluations with negative result that find the whole activity to bethe wrong idea and that would be annotated as stop_activity if they camefrom the partner;
• mental notes to do something else as well that would be annotated asamend_activity if they came from the partner;
• self-corrections of approach that would be annotated as challenge_activityif they came from the partner.
17.3. activity concepts and their properties 175
Such an annotation style would turn the currently straightforward think aloud_activity annotations into something much more complicated and therefore thebase layer suggests not to make them.
Subsequent studies particularly interested in reflection phenomena will needto change this decision and possibly also further refine the concepts used.
Chapter 18Universal concepts: Miscellaneous
There are two HHI concepts that have only little semantic content: mumble_sth and say_off topic. They only serve to mark spots in the session where someelement of the dialog is largely ignored by the annotation.
18.1 mumble_sth
mumble_sth is used for utterances that cannot be annotated otherwise becausethey are incomprehensible, whether for acoustic or phonetic reasons (whichdepending on recording quality and background noise may not be rare at all)or for semantic ones. Semantic reasons may be incompleteness (often cut-off ortrailing-off utterances) or plain gibberish.
Note that what appears to be mumble_sth for the researcher may well be un-derstandable for the pair partner, even the gibberish. If the partner reacts tothe utterance, the reaction can often be used to reconstruct the illocution (if notthe wording), and then the concept appropriate for that illocution should beannotated even if the utterance itself could not be understood; use mumble_sthonly if there is no way to reconstruct the meaning. Be aware that this approachcan occasionally lead to misinterpretations; see the discussion in Section 21.7.3.
18.2 say_off topic
say_off topic represents utterances on topics that have nothing to do with thegoal of the session such as matters of private life or events in the wider workenvironment. For instance in Session CA2, C5 makes a remark regarding thefact that the session is being recorded: “I wonder what they will think, who don’tknow what we are doing here”. We should mention that such remarks and in
177
178 Chapter 18. Universal concepts: Miscellaneous
fact any indication whatsoever that the pair is still aware of being recorded isgenerally rare after the starting moments of a session throughout our data.
Part III
Other concepts
. . . in which we define the concepts that aim at non-verbal interaction employ-ing the computer, paper and pencil, the index finger, and possibly other usefulequipment.
179
Chapter 19The HCI/HEI concepts
An annotation with an HCI/HEI concept represents an interaction of a pairmember with the computer (HCI, human-computer interaction) or the remain-ing environment other than the partner (HEI, human-environment interaction).There are currently only eight simple interaction types or purposes (write, search,explore, verify, read, sketch, show, and do), the concepts for which all use the same,generic object sth (short for something) only. This leads to a coarse modeling ofHCI/HEI activities, which is appropriate because the base layer puts its focuson utterances. The modeling is just enough to serve as the nucleus of a fullermodeling of HCI/HEI issues. Later studies interested in action (rather thanonly in dialog) will have to introduce a additional concepts.
The maximum granularity of an HCI/HEI annotation is called one activity entity.An activity entity is a sequence of actions guided by one short-term goal. Thegoal can be explicit (e.g. defined by a previous design or step episode) or tacit;the sequence can be expressed by one HCI/HEI annotation or several; the baselayer does not model the activity entities themselves.
The above granularity notion can lead to near-arbitrary segmentation for tacitgoals, cannot cope well with goals that change during execution, and hardlygets a grip on the way in which the execution may occur in multiple, uncon-tiguous stretches of time.
The notion of activity entity is central to understanding the HCI/HEI concepts:Although these concepts often represent physical activities, they are not meantto characterize these physical activities as such. Rather, a respective annotationshould cover the intellectual process that underlies the observable physicalactivity (if any) and holds together its parts, see Example 19.1. This is difficultto do properly, given our behavioristic ideal (Section 2.3.4), but we at leastattempt a reasonable approximation.
181
182 Chapter 19. The HCI/HEI concepts
Here is a short overview of what the verbs mean (in the order of their subse-quent description):
• write: editing product (or product-related) computer artifacts
• search: manual or automated search for well-defined target items
• explore: investigate and analyze in or among artifacts
• verify: checking the suitability of the modifications performed on artifacts
• read: reading aloud information shown on the screen or in paper docu-ments
• sketch: graphical sketching on paper or by computer
• show: pointing to elements or sections of physical or non-physical artifacts
• do: everything else not covered by the above concepts
19.1 write_sth
write_sth addresses writing activity in product artifacts (such as program code)or product-related artifacts (such as configuration or documentation files).
Writing activity should not be confused with typing. While typing is a necessarypart of it, activity connected to the typing is also part of the writing activity, suchas proofreading, correcting, near-range screen navigation, and in particularthinking (before typing, in between, and even after). The visibility of severalof these parts is limited, so we will need to use context indicators and applyour best judgment. For instance in the first example on page 168, after typingand speaking the word “projects”, the actor hesitates for about a second beforefurther typing, meanwhile saying “um”, and later makes two more typingpauses during which he remains silent. Neither of these, however, should beconsidered to terminate the write_sth because from a semantic point of view itall clearly belongs together (which may not appear obvious in the transcriptprovided, but was reasonably obvious for us in the actual session recording).
The editing aspect of write_sth needs not be fulfilled by direct keyboard input;semi-automated mechanisms such as search-and-replace or the application ofa refactoring operation also count.
A write_sth ends when the goal is reached or substantially changed, when abreak occurs, when the driver changes, and when some other HCI/HEI conceptneeds to be annotated for this actor. It does not automatically end when HHIconcepts need to be annotated or when an HCI/HEI concept is annotated forthe partner. Here is a complex case of write_sth:
19.2. search_sth 183
Example 19.1: Episode from Session BA1 (starting 13:55:24) in whicha lot of dialog occurs during a single write_sth. There was a B1.agree_design just previously.
(1) B1.explain_finding, 8 seconds
“That’s then total <*starts editing*> independent of the (..) implementation.As long as they’re independent (.), or not?”
Start think aloud_activity, start write_sth. B1 explains why the designproposal is good. The “or not?” is rhetorical.
(2) B2.agree_finding, 1 second
“Hm.”B2 agrees immediately.
(3) B1.agree_design, 1 second
“We can try.”
This refers to the original proposal. B1 does not stop editing.
(4) B1.explain_finding, 3 seconds
“<*stops editing*> Er, what are we (!...!) Have we even (!...!) Ah, no, ourscript is running (!...!). Right. OK.”
After a very short pause, B1 thinks aloud and arrives at an insight.
(5) B1.amend_design, 2 seconds
“And one needs to be id_to_code now.”
After a short pause, B1 refines the proposal: One of the two code_to_id
calls must become id_to_code instead.
(6) B1.explain_finding, 13 seconds
“We have a code: id_to_code (!...!) <*continues editing*>”
think aloud_activity ends after the utterance. B1 makes further changes tothe same line. He then switches into the browser to test the change; thisends the write_sth.
19.2 search_sth
search_sth represents the search for well-defined items in digital (HCI) or physi-cal (HEI) documents, by manual or automated mechanisms, in an efficient orinefficient manner, to either locate something or to check its existence.
184 Chapter 19. The HCI/HEI concepts
We call an item well-defined if the actor appears to believe to know the itemwell enough to be able to specify it explicitly by an identifier, a file nameplus line number (typically from an error message), a regular expression, etc.Automatic search includes the time of waiting for its results.
Example 19.2: Episode from Session BA1 showing a two-part search_sth.
(1) B1.propose_step, 2 seconds
“Let’s look where that’s used in here.”B1 proposes to search for calls to a method; he points to a method name(show_sth), then starts the search using the Eclipse search function (startsB1.search_sth/B2.search_sth).
(2) B1.explain_finding, 4 seconds
“Workspace (!...!) (;;) Workspace is (~)”
Start B1.think aloud_activity. The Eclipse search dialog is open, the searchscope is to be selected as either Workspace (default, currently selected) orWorking Set. B1 starts the search as is. The search reports “Scanning file 1of 2348”.
(3) B1.say_off topic, 1 second
“Muffins afterwards!”
Unrelated remark after 2 seconds.
(4) B2.say_off topic, 3 seconds
“First work, then reward.”
B2 replies laughingly. The search is still running.
(5) B2.explain_finding, 2 seconds
“We have 2350 files? Wow.”
After two seconds, B2 takes notice of the “Scanning [...]” display.
(6) B1.explain_finding+B1.amend_step, 6 seconds
“Eeeeer, yes. That’s total nonsense of course. We could search in our Work-ing Set. I thought I hadn’t checked out anything else, but (!...!)”
After another second, B1 recognizes that the search scope was ill-chosen(finding type TC). While speaking, he stops the search. The utterance endsthe B1.think aloud_activity. He starts the search again, this time usingWorking Set scope. The pair waits for its results quietly. The results appear,ending the search_sth.
19.3. explore_sth 185
19.3 explore_sth
Exploring something means to investigate or probe a set of digital or physicaldata with respect to items that are not well-defined (contrast with search_sth).The goal is either to determine whether such an item exists at all (such as amethod providing a certain functionality), or to locate the (or such an) item, orto understand a set of items better (such as looking for ideas what to do next orhow).
Exploring may look through the content of one file, the content of several files,the names of files, information provided by the IDE (such as lists of methodnames), the results of program runs (including compilation error messages, butsee verify_sth in Section 19.4), the content of a database (including IDE settingsand so on), etc. Such activity may or may not have physical symptoms such asscrolling.
For instance in Session ZB7, the current driver Z20 suggests to look “whatmethods the Subscriber offers” and immediately starts scrolling through theTopicSubscribe JavaDoc webpage and then the MessageConsumer JavaDocwebpage (explore_sth); he verbalizes the names of several methods of potentialinterest.
The exploration may be superficial or thorough. Quiet reading (and even purethinking) of material counts as exploration and reading aloud to oneself countsas exploration as well. Several exploration goals covered in one contiguousexploration procedure count as a single explore_sth.
In contrast, reading aloud to the partner is read_sth (Section 19.5). Checkingthe outcome of previous work is verify_sth; explore_sth does not apply to itemscreated during the same session (Section 19.4) if these items are part of artifacts(as opposed to execution results). Discriminating explore_sth from a manualsearch_sth can be difficult. Even recognizing an explore_sth at all may be difficultbecause no physical activity may be obvious; only context information canhelp.
Example 19.3: Episode from Session BA1 beginning 13:42:11 and show-ing an explore_sth. B1 had previously issued a wget http://localhost
command line call (do_sth); the result analysis has sufficient structure toturn it into explore_sth.
(1) B1.explain_finding+B1.ask_knowledge, 1 second
“Hey. Hm. What’s cooking there?”
The console displays “Can’t resolve hostname ’localhost’. Connection re-fused”. Starts B1.explore_sth and B1.think aloud_activity.
(2) B2.propose_hypothesis, 1 second
186 Chapter 19. The HCI/HEI concepts
“Firewall?”Starts B2.explore_sth. B2.think aloud_activity: Apparently B2 is exploring,too.
(3) B1.explain_finding, 1 second
“Can’t resolve hostname ’localhost’.”B1 considers this the interesting part. Ends B1.think aloud_activity.
(4) B2.propose_hypothesis, 2 seconds
“Maybe only the (~~)?”
B2.think aloud_activity: A new idea (understandable for the partner) after 2seconds of silence.
(5) B1.agree_hypothesis
“(Yes.)”
Start B1.think aloud_activity: Agreement after a pause.
(6) B1.explain_finding, 1 second
“(~) is OK.”
The utterance ends B1.think aloud_activity and also B1.explore_sth/B2.explore_sth. B1 proceeds with a new proposal and switches fromthe console into the browser.
explore_sth represents exploration that stands for itself. If the activity occurswithin or at the end of another activity and can be considered part of that otheractivity, only a concept for that other activity should be annotated. For example,a verify_sth may consist of running a test and then examining the test’s output.The latter, by itself, would qualify as explore_sth, but since from the point ofview of the verify_sth it is an integral part of the verification process, no explore_sth should be annotated.
19.4 verify_sth
verify_sth represents activities for verifying or validating results of the pair’sprevious work done in the same session. The checking can be manual orautomated and can be review-based, analysis-based, testing-based, or mixed-mode. It includes the case of making sure that all process steps have beenperformed (as opposed to checking the product). It does not matter whetherthe actor expects to find correctness or rather incorrectness.
A verify_sth may be announced by a propose_step such as “Let’s look”. If it is notand also has no think aloud_activity, it may be hard to detect. It can contain
19.4. verify_sth 187
actions such as reading and paging through code, program outputs, log files,data displays, and other representations as well as starting compile, build,deploy, or program run processes, operating programs, and many others.
verify_sth often starts with a preparatory step, such as starting the program tobe tested or opening a file to be reviewed. Implementing automated tests isnot verify_sth. The proofreading usually done as part of write_sth is write_sth,not verify_sth (but semantic checking after a write_sth is verify_sth). Corrections(including commenting) performed during a verify_sth terminate that activityand are write_sth.
If the verification of the pair’s work-results directly leads to the investigation ofother material, it may be unclear whether this should be considered to end theverify_sth and start an explore_sth or rather be considered to continue a complexcase of verify_sth.
If a test leads into a code review, it is useful to annotate two separate verify_sth.If the pair does not verbalize the result of the verify_sth, it can be difficult todecide when it ends. Like for explore_sth, identifying when the partner is or isnot taking part in the verify_sth can be difficult and is largely an open problem.Subsequent studies need to decide whether to modify some of these criteria.
Example 19.4: Episode from Session CA2 (12:25:39–12:26:23) in whichC2 performs two HCI/HEI activities at the same time: a do_sth during averify_sth. The pair had previously modified some code.
(1) C2.propose_step, 1 second
“OK, let’s go.”
C2 proposes to test the application and clicks ’Run’ to start it. StartsC2.verify_sth. Is a C2.think aloud_activity.
(2) C2.ask_knowledge (or perhaps C2.explain_finding), 2 seconds
“Huh, (.) our <**application name**> (.) why can’t we get at it?”
C2 moves the mouse to access the invisible Windows taskbar in order tosee whether an instance of the program is already running, but the taskbardoes not appear: C2.do_sth. C2.think aloud_activity (a separate one, becauseit refers to a new activity entity).
(3) C5.explain_finding, 3 seconds
“It needs to do a rebuild – it is rebuilding right now”
While he speaks, the window of the new run appears at center-screen.
(4) C2.disagree_finding, seconds
188 Chapter 19. The HCI/HEI concepts
“That has nothing to do with the taskbar not working.”
C2 disagrees and opens the Eclipse Console view.
(5) C5.ask_knowledge, 1 second
“What taskbar?”C5 had not previously understood what was C2’s problem.
(6) C2.mumble_sth, 1 second
“(~Hm. Oh.)”
Meaning unclear.
(7) C5.ask_knowledge, 1 second
“(~What ta) (!!...!!)”
C5 asks again but gets interrupted.
(8) C2.mumble_sth, 1 second
“(~)”
Incomprehensible interjection.
(9) C5.ask_knowledge, 1 second
“Is, is down?”
C5 asks whether the taskbar is (routinely) hidden.
(10) C2.explain_knowledge, 2 seconds
“No, I don’t have one. (.) Just look.”
C2 explains he considers the taskbar gone, not just hidden.
(11) C5.explain_knowledge, 5 seconds
“But it appeared for me a moment ago.”
C5 grabs the mouse that C2 is holding (C5.become_driver, starts C5.do_sth,C5.think aloud_activity). He moves it down to the edge of the screen, but notaskbar appears. (end of C5.do_sth).
(12) C2.explain_finding, 2 seconds
“We have an <**application name**> still running.”
It is unclear how C2 knows. Meanwhile, the startup of the new run fin-ishes, is ready for testing.
(13) 6 seconds
19.5. read_sth 189
–C5 starts testing the newly-run application: Starts C5.verify_sth.
(14) C5.explain_finding, 1 second
“OK”C5.think aloud_activity: C5 finds the application to work correctly. End ofthe C5.verify_sth started in entry (13).
(15) C2.agree_finding, 1 second
“Fine.”C2.think aloud_activity: C2 agrees. End of the C2.verify_sth started in en-try (1).
(16) C5.propose_step, 1 second
“Now we can check in.”This suggestion how to proceed makes sure the verify is over.
19.5 read_sth
By read_sth one should annotate those (parts of) activity entities where the actorintentionally reads aloud (and verbatim) information shown on the screen, in aprinted document, etc. – whether to communicate the information or only todirect attention (the partner’s or one’s own) to it. In contrast, casual reading(e.g. during a verify_sth) that has more the character of speaking to oneself isnot read_sth. In HHI terms, read_sth will often be explain_finding of type D.
19.6 sketch_sth
The creation of sketches, whether on paper, on a whiteboard, on a computer,or elsewhere is annotated as sketch_sth. This is typically performed to clarifythoughts, whether the actor’s own, the partner’s, or both, and whether theclarification is directed more to the partner, the actor, or both.
Sketching is a potentially very interesting part of pair programming andsubsequent studies interested in it should probably discriminate the above-mentioned cases.
19.7 show_sth
Pointing to certain information in a physical or non-physical artifact is an-notated as show_sth if it is the primary activity. The pointing can happen by
190 Chapter 19. The HCI/HEI concepts
any means such as the mouse cursor, highlighting via a mouse-generated orkeyboard-generated text selection, a pen, a finger, and conceivably also a nod(if specific), etc.
For instance, a developer explaining a stretch of code may point to identifiersor control constructs as she goes. Again, it is the underlying goal that definesthe activity, so multiple pointings go together into a single show_sth if theycontribute to the same goal. Pointing may also serve to provide emphasis as inExample 10.1 (2).
In contrast, if the pointing is only part of a different primary activity, such asexplore_sth or verify_sth, where the reader may for instance follow the currentfocus with the cursor, no separate show_sth should be annotated to keep theannotation economical.
19.8 do_sth
Anything that is not addressed by any of the concepts introduced previouslycan be annotated as do_sth. In principle, it could be used for almost any physicalmovement at all or at least for minor computer actions such as clicking a button– but obviously that would as such hardly reflect a goal as base layer activitiesshould and so should probably not be annotated separately.
In contrast, a good example of do_sth could be the cleaning-up of the IDEworkspace by closing multiple editor windows. Depending on the goal of yourstudy, there might be many such meaningful actions that fall under do_sth inthe base layer – but a do_sth annotation provides too little meaning.
So please consider do_sth to be a kind of beacon: Whenever you feel tempted touse it, also consider whether you should leave out that annotation as most likelyunimportant or invent a more specific concept to represent the phenomenonmore meaningfully. Using do_sth is advisable only if neither is the case.
19.9 On drivers, observers, and co-action
In order to understand pair programming by qualitative analysis, it is obviouslyimportant to record who is the actor of each event being conceptualized. For aspeech act represented by an HHI concept instance, this is trivial. In contrast,while the HCI/HEI concepts presented above are all based on an observable(at least in principle) physical act as well, it is the underlying goal that reallycounts and it may be far from obvious whether P1, P2, or both are pursuing it.
HEI and even HCI activities can be performed not only by the person cur-rently in possession of the keyboard (the “driver”) but also by the other (the
19.9. On drivers, observers, and co-action 191
“observer”)1 In order to understand the phenomena in the session, we shouldask ourselves who is the actor (or actors) for each HCI/HEI annotation andassume that co-action, both partners sharing the activity intellectually, may becommon.
This is not easy even for the physical act itself: The observable physical actis clear and obvious for some concepts (such as for write_sth, sketch_sth, andshow_sth, unless hidden by limitations of the session recording) but often subtlefor others (in particular verify_sth). And even a partner not participating ina physical computer-operating act may well co-perform the correspondingintellectual act.
The base layer suggests the following criteria as a starting point for assigningHCI/HEI actorship: Unless there is specific evidence against it. . .
• . . . consider the main physically active pair member as an actor. Whereoperating the computer is involved, this will be the driver, but wherefingers, pencils, or eyes suffice as the active infrastructure, it can also bethe observer.
• . . . consider apparently concentrated gazing at the monitor (if it can bediagnosed) to be an important indicator (in favor or against actorship,depending on the situation).
• . . . consider each person who proposed the activity or participated in itsdiscussion as an actor.
• . . . consider each person verbalizing part of the activity as an actor.
• . . . consider each person asking or answering questions pertaining to theactivity during the activity as an actor.
Not only the participation itself in some activity may be hard to diagnose, itsexact beginning and end may be as well (see also Section 21.5).
Overall, the base layer cannot provide sufficient criteria for reliable assignmentof HCI/HEI activities to the right actors. However, approximate correctness ofthe annotation may be sufficient for many purposes.
1We have even seen cases where the “observer” obtained full control, telling the “driver” whatto do on a keystroke-by-keystroke basis (“Down, Down, Down, Return”).
Chapter 20Supplementary concepts
The base layer provides a few very rough additional concepts that may beuseful on some occasions.
20.1 become_driver
The actor takes control of the keyboard and mouse. Cases such as a pairmember taking the mouse only are not covered.
20.2 work in parallel_sth
Both partners are independently working on different activities. This simplisticconcept can either be used without an actor (work in parallel_sth) or with pairsof annotations (P1.work in parallel_sth+P2.work in parallel_sth), allowing moregranular use.
For studies interested in such behavior, in particular when analyzing dis-tributed pair programming based on tools such as Saros1 that allow the pairto also each use their computer independently, much more refined ways ofdescribing the degree of coupling of the two activity strands will be needed.
20.3 work alone_sth
The actor continues work without any partner at all because the partner leftthe workplace.
1http://en.wikipedia.org/w/index.php?title=Saros_(software)&oldid=566544288
193
194 Chapter 20. Supplementary concepts
20.4 wait for_sth
The “actor” suspends all activity until a certain expected event occurs, such asthe results arriving after a long-running search (Section 19.2) or test. Typicallyused together with concepts such as search_sth or verify_sth.
20.5 react to_interrupt
Marks a point where the pair stops its work due to an external event such as aphone call coming in. Such an annotation explains why no further annotationfollows for some time afterwards.
Part IV
Using the base concepts
. . . in which we summarize how to use the base concepts as they are (Chap-ter 21), how to adjust them to your particular study (Chapter 22), and how tointroduce your own layer(s) of concepts in addition (Chapter 23).
195
Chapter 21Guidelines for annotating
If you have read the concept descriptions in Chapters 4 to 17 attentively, youhave seen not only many concept-selection rules, but also a number of hints onhow to operationalize the annotation process. Both are fragmented over manypages, so we summarize them in this chapter.
21.1 How to pick appropriate HHI concepts
The many details of each concept as presented in the previous chapters notwith-standing, here are the principles of annotating appropriate HHI concepts toutterances:
• Your goal is to determine the primary illocution of an utterance. Thelength of utterances is determined by what still belongs to the sameillocution.
• Describe the utterance’s possible illocution in your own words. Makesure you notice if the speech act is indirect so you can cleanly tell apartthe secondary (obvious) illocution from the primary (actual) illocutionand use the primary one. There are many more different illocutions thanthere are different verbs in the base concepts so you will usually need tomake a subsumption step to determine which base concept (combinationof a verb and an object) fits best with the overall content of the utterance.Best fit will often depend on specifics of the current pair programmingsession context. There are many examples throughout the book in whichthis problem is discussed; start for instance in Section 4.2.1.
• If it is an initiative utterance, annotate the most specific base concept thatapplies. (Roughly speaking, specificity decreases from chapter to chapter.See also Section 11.3.)
197
198 Chapter 21. Guidelines for annotating
• If it is a reactive utterance, observe the episodes principle (Section 2.3.6).
• If no base concept appears to apply properly, consult Chapter 22.
• If more than one base concept applies, consult Section 21.4.
While using this procedure, be aware of two inherent limitations: First, inthe best possible world, each concept would be defined by stating all of itsnecessary and sufficient conditions. This goes back as far as Aristotle and whileit works well in mathematics, it does not apply well1 in the world of humanlanguage and action. Thus, the manner in which we define the base concepts ismore akin to the idea of Wittgenstein’s Familienähnlichkeit2 (or other kinds ofprototype theory3) combined with some amount of ostensive definition4.
As a result, the base concepts on the one hand may not precisely cover aparticular given case exactly, but on the other hand are open for modificationto repair that problem. Mindless application of fixed rules is definitely not amanner of working with the base concepts that is likely to create useful results.
Second, not only the base concepts are limited, the observer is limited as well:There is no way you (or anyone, including the pair members themselves) couldguarantee to have determined the “right” illocution for a given utterance.
From our pragmatist point of view, both of these restrictions are not overlydisturbing, because perfection is not required, only usefulness is.
21.2 How to pick appropriate HCI/HEI concepts
The criterion for determining an appropriate HHI concept for an utteranceis the utterance’s illocutionary act. We use an analogous criterion for theHCI/HEI concepts: What does the activity do (in terms of its intention, goal,purpose) in the context of the session?
For instance, scrolling down through a file might be the execution of a verify_sth, a manual mode of search_sth, some part of an explore_sth, and perhaps some-thing else entirely (do_sth). In particular, it might be a displacement activity5.As mentioned in Section 17.2 (see the possible example there), displacementactivities are not modeled in the base layer but one may want to model themin subsequent studies.
1http://en.wikipedia.org/w/index.php?title=Concept&oldid=567169993#Notable_
theories_on_the_structure_of_concepts2http://en.wikipedia.org/w/index.php?title=Family_resemblance&oldid=5650123813http://en.wikipedia.org/w/index.php?title=Prototype_theory&oldid=5406758174http://en.wikipedia.org/w/index.php?title=Ostensive_definition&oldid=
5446920515http://en.wikipedia.org/w/index.php?title=Displacement_activity&oldid=
558153583
21.3. What to consider as context 199
21.3 What to consider as context
Many times we have used the term context when discussing that an utterancecan usually not be interpreted based on its wording and pronunciation aloneand that further information needs to be used as well but we have neverexplained what context really means.
From a practical point of view, the applicable context is restricted to whatis known to the researcher to a sufficient degree. In our setting, a relevantrestriction will often be imposed by the scope of the current pair programmingsession. The following items may or may not be available to the researcher aspart of the applicable context:
• The goal or task set for the session.6
• Everything said in the session so far (HHI).
• Everything done in the session so far (HCI, HEI).
• All information shown on the screen (and noticed by a pair member!)now or previously in the session.
• The personality, physical state, and mood of the pair members, theirgeneral and their short-term social relationship, etc.7
While the second and fourth of these are often reasonably well observable, theobservability of the others tends to be severely restricted. The researcher’sunderstanding of the actual context is thus limited.
21.4 When to use double HHI annotations
In order to keep the annotation process manageable, the base layer attempts tonormally assign only a single HHI concept to each utterance. This principleis not always appropriate. You may occasionally need two (or possibly more)annotations to best describe the current phenomenon. Here is the list of suchcases as known to us8:
1. Proposals (or agreements, disagreements, challenges) that are “packagedinto” (that is, take the form of) explain_knowledge or explain_finding utterances.These are indirect speech acts in which both the secondary (explain) and theprimary illocution are of major interest. In such cases, both concepts should be
6Such information can and should be gathered by other means outside the actual sessionrecordings, such as an interview or questionnaire.
7Ditto.8You may occasionally encounter additional ones – but if you think you do, re-read the
annotation principles in order not to open the floodgates prematurely.
200 Chapter 21. Guidelines for annotating
annotated; see Section 6.3.6, Example 16.2, Example 17.2. There are also casesin which it is ambiguous whether the explain is primary or secondary; they arehandled in the same way. Also, instead of explain you may see challenge as inthe propose_step/challenge_finding pair of Example 12.6.
2. Utterances containing subutterances9 that need to be annotated differentlybut where splitting the utterance up is not possible or not wanted; see Sec-tion 10.2.3. For the common case of finding utterances that explain some existingknowledge as well, you will need to decide how to handle them in subsequentstudies: double annotation for completeness or only the finding for simplicity.
3. Utterances that are ambiguous with respect to the base concepts. It does notmatter whether the ambiguity appears to exist in the speaker’s head as well (asin Section 9.3.5 and Example 16.6 (2)) or appears intended by the speaker (as inSection 6.3.5).
4. Indirect speech acts where the secondary illocution is of a type that is in thefocus of your particular studies; see Section 9.3.5.
5. Design proposals made as part of strategy proposals.
6. Implicit action announcements as discussed in Section 21.6.1.
7. Any activity utterance that is not only that.
Any HCI/HEI annotation that happens to coincide with an HHI annotation isnot a double annotation at all in this sense.
Note that this list concerns only the base layer as such. Your own subsequentstudies will likely deserve their own rules for the use of double annotationsthat are aligned with the research question and may have to modify the abovelist considerably.
21.5 How to segment utterances
For many types of qualitative study, the segmentation of the raw data is acrucial and difficult step and consumes a large fraction of the overall effort –yet we have not talked about this at all so far. Why not?
Because in the base layer’s approach, asking for “how to” segment is not aquestion that has an explicit answer. It has no explicit answer because thechoice of concept to use for an annotation and the choice of segment to whichto assign that concept are determined at the same time and influence eachother.
The following is the best approximation to “segmentation rules” for the baselayer:
9Also, utterances the meaning of which contains such subutterances, i.e., that can be paraphrasedsuch that the subutterances emerge.
21.6. How to handle specific phenomena 201
• Segmentation is a holistic process concurrent with assigning the concepts.
• If you have decided to annotate the HHI concept X and your candidatesegment covers a whole utterance, covers the respective X completely,but does not cover more than the X, then you have chosen a suitablesegmentation.
• If your segment covers less than a whole utterance and the remainingpart needs to be annotated with a different HHI concept, then you havealso chosen a suitable segmentation.
• If your segment covers less than a whole utterance and the remainingpart needs to be annotated with the same HHI concept, extend yourutterance unless the remaining part is clearly a semantically separate anddifferent instance of X.
Apply the same idea analogously to the HCI/HEI concepts as well (“utterance”becomes “activity”). During your annotation process, you should performconstant comparison and always consider not only the annotations themselvesas preliminary, but the segments to be annotated as well – in particular (butnot only) for HCI/HEI concepts.
21.6 How to handle specific phenomena
21.6.1 How to annotate implicit announcements
A question or other utterance may sometimes reveal that the speaker intendsto do something although the intended action is not mentioned; see Exam-ple 16.2 (1). We call such a disclosure, whether conscious or unconscious,an implicit action announcement. Such announcements are not easy to detect,because in comparison to explicit ones they require the researcher to have amuch better understanding of the session’s technical meaning. However, as thepartner may detect that intention and this may influence the session’s coursesubstantially, you should annotate the implicit propose whenever you detectone.
Depending on their research question, subsequent studies may have to definerules for limiting the effort put into detecting such implicit announcements ina well-defined way.
21.6.2 How to annotate thematic shifts
One of the primary intentions during the creation of the base layer was makingvisible the structure of basic dialog episodes; the approach chosen for doingso was by marking intra-dialog relationships (Section 2.3.6). Via the notion
202 Chapter 21. Guidelines for annotating
of initiative versus reactive verbs (Section 3.5), this basic approach led to thestructure of concept classes as explained in the chapters above. Each suchconcept class essentially represents a topic type. An episode in the primitivesense of the base layer is basically a sequence of utterances regarding oneparticular instance of one such topic.
When using the base layer, it is therefore important to correctly identify thetopic (concept class) at each point. The base layer provides help for doing thisin various forms, starting with the basic definition of what holds together aconcept class (such as “What is a design proposal?”, Section 4.1), over some-times a few helper concepts that distinguish important subtypes (such as thevarious strategy types (Section 9.1) or hypothesis types (Section 13.1)), down tosubtle additional rules for individual concepts such as the idea that an explain_knowledge must not express any doubt (that would make it a propose_hypothesis)but an agree_knowledge may.
Nevertheless sticking to one concept class within an episode is not always theright thing to do: Sometimes, a reply does not react to the primary topic set bythe previous utterance but on something else such as a subaspect of it. Suchcases may constitute a change of topic which we call thematic shift (or simplyshift for short). For instance in Example 21.1, B2’s reply neither pertains toB1’s design proposal nor to the hypothesis stated along with it. Rather, it onlypertains to a finding that is implicit in the proposal:
Example 21.1: Episode from Session BA1 (14:57:00–14:57:19) in whichan annotation is used only due to a thematic shift. For description anddiscussion of the content you will need to consult the whole of Sec-tion 21.6.2.
(1) B1.amend_design/B1.explain_finding+B1.propose_hypothesis
“But then why don’t we also, er (.) kick out the one for this id <*points toelement*>? (.) Or do they do that explicitly somewhere else again?”
“They” are the previous programmers of the code.
(2) B2.agree_finding
“That’s a good point. That’s missing here.”
B2 says this after the pair has sat silent for 10 seconds.
In this episode, the pair is discussing a modification of a for loop that removesobjects from a cache and that (like most of the surrounding code) was writtenby other programmers. B2 had previously suggested a particular deletion(propose_design) and B1 now amends that by another. B1’s utterance has threeaspects that can be paraphrased as follows:
21.6. How to handle specific phenomena 203
• “This element needs to be deleted too.” (explain_finding)
• “I suggest to do it right here.” (propose_design)
• “But perhaps it’s already being done elsewhere.” (propose_hypothesis)
The design proposal is the main aspect and would hence normally suppressthe annotation of the finding (Section 4.2.1), because the finding is not statedexplicitly. B2’s reply ignores the design proposal, ignores the hypothesis, andonly refers to the implicit finding. B2’s utterance clearly should be annotated asagree_finding. What the base layer suggests to do in addition is adding anothercode to the previous utterance that “prepares the ground” for the concept usedfor the reply: We annotate the finding aspect (that would normally have beenmerely implicit) in addition to the already-present design and hypothesisaspects.
This is a general rule and the whole point of this short chapter: If a thematicshift from class A to class B occurs in a reply, then
• annotate the reply by a B concept even if that breaks the normal episodestructure, but
• also consider adding a suitable corresponding B concept to the previousutterance (the one to which the reply refers).
The addition should be made if the B concept is appropriate according to itsown definition and had only been suppressed due to the definition of theA concept used and/or the A-versus-B discrimination rules. We call suchannotations shift-motivated annotations. The addition should not be made if byitself the B concept is inappropriate for the previous utterance.
Later studies may additionally or alternatively want to introduce an explicitshift concept or property if that better suits their respective research goal.
21.6.3 How to annotate repetitions
If the semantically (but not necessarily syntactically) same thing is said againby the same speaker, there are four cases:
An immediate repetition occurs within the same utterance. This is not annotatedseparately but is simply considered to be either emphasis or meaningless andlumped together with the first.
An early repetition occurs when the session context has not yet changed substan-tially. Its dialog role will usually be to make sure the original utterance is notlost or ignored. Such repetitions will be annotated with the same concept again.
204 Chapter 21. Guidelines for annotating
The fact of being a repetition is not modeled by the base layer; subsequentstudies may want to introduce concepts for doing this.
An early repetition of an explain_finding can be a special case: If the dialog topichas not progressed since the first time the finding was stated, the above earlyrepetition rule applies; we just annotate explain_finding again. If however,the dialog has touched a different topic in the meantime (such as the partnercommenting on something else than the finding), the same content will then beannotated as explain_knowledge, because the insight is now considered to havebecome part of existing knowledge. Do not apply this rule if you find clearsymptoms that the speaker had forgotten his or her earlier insight (and not justits relevance!).
A later repetition is annotated as is most appropriate for its new context.
21.6.4 How to annotate incomplete agreement or disagreement
The agreement (or disagreement) with proposals and explanations is oftenless than one hundred percent. So far, we have seen two cases: Either thespeaker is unsure of his or her own judgment (as in Section 4.2.10), or he orshe agrees with only a part of the previous utterance and disagrees with someother (which may be common for strategies, as in Section 9.2.9). If a challengeannotation is not appropriate, the base layer annotation should then simply bean agree or a disagree – whichever sentiment appears to dominate.
Subsequent studies, however, may need to introduce concepts for also annotat-ing the doubt and/or partial criticism.
21.6.5 How to annotate self-corrections
Utterances that extend (amend) or contradict (disagree, challenge) a previousutterance need not come from the partner; they may also come from the samespeaker as in Example 4.2 (amend_design), Example 6.3 (amend_step), or asdiscussed in Section 12.2.4 (challenge_finding). This is not unusual and may beimportant for the course of the session.
The base layer does not express the fact of self-correction in any way, it isonly (ambiguously) visible from the overall episode structure. Subsequentstudies may wish to introduce concepts for annotating self-corrections as suchexplicitly.
21.6.6 How to annotate justifications
One particular type of explain_knowledge utterance is the justification of a pro-posal. From its frequency and importance alone, justification could have been aseparate concept class. However, to justify something is a form of illocution
21.7. Method hints 205
and in the base concept set illocutions are expressed by the verbs, not theobjects.
Thus, there is no indication (in an annotation that uses only the base layer)of justifications and suitable concepts (probably just attributes) for modelingthem may be one of the first additions that subsequent studies interested inthese phenomena should make.
21.7 Method hints
The guidelines in this book so far may be sufficient to define what the resultof your annotations should look like (unless you chose to modify them asdiscussed in Chapter 22). However, as you may have guessed already fromreading the examples, the session reality you will face can be very peculiar,leaving you perplexed. In such moments, the following tricks may help. Theyare not meant to be used in any particular order; rather, they are part of theannotator’s toolkit much like the definitions of the concepts themselves.
21.7.1 Step back
If there were a mantra of the base layer annotator, it would be “Context, context,context!”. So if you are having a hard time deciding which concept is the rightone for the next utterance, it may be that (a) as a beginner you are not takingthe context into account enough and are rather attempting to categorize anutterance based on only its language content, or (b) later on you are looking atcontext but cannot see the forest for the trees; you are considering the previousutterances and their annotations but still cannot make up your mind what thecurrent one means.
In the latter case, step back and put on your software developer hat (as inExample 6.2): What is going on there in terms of the overall programmingsession? What is the current goal? What is understood and what is unclear? Towhom?
21.7.2 Paraphrase
If that does not help and you are still torn between two concepts, it mayhelp to use your context understanding for re-expressing the utterance in newwording.
For instance in Session BA1, B2 asks
“Should we store both values or should (!...!). (..) Or is last_changesufficient? Do we really need last_request?”
206 Chapter 21. Guidelines for annotating
A first-time user of the base layer might immediately annotate this as ask_knowledge, but let us assume you have meanwhile learned to mistrust thesyntactical form and ask yourself whether maybe this ought to be viewed aspropose_design? How would you make the decision between the two? You useeach of these possibilities and rephrase the essence the utterance would thenhave.
If it was indeed propose_design, it ought to mean “I suggest to use last_changeonly and not use last_request”. In this case, this does not sound right, becausenot handing over last_request to the script had been suggested previously,so the original utterance above would be a rather strange way of suggestingsomething closely related and is thus probably not intended to be a proposal.
Counter-check: If the utterance was indeed ask_knowledge, it ought to mean“I do not understand why we should store last_change as well as last_request”.This meaning fits nicely into the context so it is likely the right interpretationand hence ask_knowledge should be annotated. See also Example 12.2 (3).
21.7.3 Peek into the future
If paraphrasing also does not help, it is time to use your ultimate weapon:Your super-human power of seeing the future. An often very helpful indi-cator towards an appropriate annotation for an utterance is the reaction ofthe partner: If the partner apparently interpreted the utterance as X, maybeyou should do so too rather than annotating Y? If the speaker subsequentlyprotests, this may obviously be the wrong idea, so you should do a little furtherpeeking to safeguard against that possibility. See the discussion in Section 9.3.7.The technique will be particularly valuable when you need to understand amisunderstanding where the respective utterance may appear totally illogicalat first; see again Example 19.4.
Beware, however: The partner’s reaction may actually be a misunderstandingand the speaker simply too lazy, too tired, too shy, too slow, too inattentive, orany of a dozen other things to protest. In that case, the annotation resultingfrom peeking into the future would be wrong. It may be a tiny little bit wrongonly, because the speaker may not have been fully clear of his or her ownintentions to begin with. It may be wrong but without consequence, becausethat particular annotation difference does not make a difference with respect toyour research question. But if your research question has anything to do withthe precision or reliability of communication, with contingency or serendipity,or with shifts (Section 21.6.2) you rather want to detect and annotate ambiguitythan making this kind of annotation mistake. So like all superheros you shoulduse your power with great care.
Chapter 22Guidelines for modifying the baseconcept set
Whatever your research question is for a subsequent study that uses the baselayer, the base concepts alone are not likely to get you an answer. You willusually require additional and/or different concepts to cover all your annota-tion needs in order to produce your insights. Remember that the base conceptsshould not be viewed as a coding scheme but rather as a starting point for yourown understanding and modeling; see Section 2.1.
For instance, the clean differentiation between finding and knowledge (here andin Chapter 16) and between them and the other HHI concepts (Chapters 4 to10) required an extremely lengthy research process. We are convinced that theresulting concept class structure is very useful for pursuing a broad varietyof research questions. Nevertheless, it may be ill-suited for your particularquestion. Feel free to kick parts or all of it overboard as soon as you haveprecisely understood why you are doing it and have developed some idea ofwhat you will gain. (Be advised that you will likely not have a good idea whatyou will lose.)
We cover modifications and additions within the topic realm of the base conceptset in this chapter and outside of it in the next chapter.
22.1 What makes a good concept set
A good set of concepts for analyzing pair programming should fulfil at leastthe following two quality criteria:
• Adequacy: It should allow to express all phenomena of interest ade-quately (that is, without too much distortion), with sufficient precision,
207
208 Chapter 22. Guidelines for modifying the base concept set
and in a matter that explains (“theoretical coding”, see Section 1.4.4)rather than merely describes.
• Parsimony: It should sufficiently limit the intellectual effort requiredduring the annotation process so that the process remains manageable.
It is not easy to create an adequate set of concepts anyway, but it becomes verydifficult if you strive for parsimony at the same time. There must neither betoo many concepts nor must the concepts be overly diverse and arbitrary.
The base concept set has nice properties in this respect: The overall numberof concepts is modest, the concepts are nicely grouped into concept classes,and even the individual concept classes are similarly structured and constantlyre-use almost the same criteria for discriminating the concepts. Furthermore,the concepts are fairly generic and can be applied uniformly across studies ona diverse set of topics, thus connecting those studies to one another. This char-acter should be maintained when modifying and extending the base conceptset.
22.2 When to shift a boundary
If you find that for a particular phenomenon the base layer does explain howit should be annotated but that annotation would blur a distinction that isimportant for your research question, feel free to change that particular ruleand shift the boundary between certain base concepts.
If that need arises for a detail rule that only discriminates one pair of concepts(from somewhere in a “Discrimination from similar concepts” section) themodification is usually unproblematic. Just make sure you thoroughly docu-ment (including rationale) all such deviations from the normal definition ofthe base concepts so that the meaning of your annotations can be reproduced.We have already marked many plausible candidates for such alterations in therespective places.
If, however, the modification need arises for a more general rule that discrimi-nates one verb from another for all concept classes or one object from anotherfor all its verbs, be aware that the modification may shatter the integrity of thebase concept set as a whole if you are not careful. It is a good idea to sleep oversuch a decision, discuss it with somebody else (perhaps with us?) and then notdo it – resort to an extension instead; see Chapter 23 and the remainder of thepresent chapter.
22.3 When to add a new property value
It may happen that you encounter phenomena you are inclined to consider, forinstance, a strategy but that do not fit into any of the existing strategy types as
22.4. When to add a concept and which 209
defined in Section 9.1.
In this case, after carefully checking that your phenomenon does indeed not fitinto any of the existing types, you should not hesitate to add a new type to thelist. This amounts to refining the base layer by completing the description of aprimary characterizing attribute with respect to a case that had never occurredin our data.
It it conceivable (although we do not think it is likely) that you will discoveranother primary characterizing attribute. In this case, you would not only addproperty values but rather a complete property along with its values.
22.4 When to add a concept and which
If you arrive at the end of the instructions of Section 21.1 and have not founda base concept that characterizes the illocution you have determined, thefirst step is asking yourself whether one of the universal concepts (e.g. aknowledge concept) can do the job. These concepts are collection pools formany different phenomena and yours may be among them if you consider theillocution less specifically. If none of them fits, continue as explained in thenext paragraph. Do the same if one of them does fit but such annotation wouldlose a discrimination that is important for your research question.
The second step is considering new combinations of existing verbs and existingobjects. For instance you might encounter an utterance that is clearly a disagree,applied just as clearly to a todo. No concept disagree_todo exists in the baseconcept set, so what are you to do? You need not get the least bit nervous insuch cases. The only reason why disagree_todo is missing from the base conceptset is that we have never seen it in our sessions. If it occurs in yours, nothingspeaks against adding it to your concept set right away. Just make sure that overtime you understand how to discriminate it from its neighbors in ambiguouscases. For instance, if the speaker provides a justification, the resulting disagree_todo+explain_knowledge might sometimes be similar to an explain_state. If youcommunicate your results, feel free to consider your addition to be part of thebase concept set, but make sure you properly explain the new concept(s) toyour readers.
The third and final step is considering to add new verbs or new objects. Forinstance, a number of times during the analysis of our sessions we encounteredutterances in which the speaker stated where a certain relevant informationcould be found (such as in certain other parts of the code, certain projectdocumentation, or certain public documentation). For instance in Session ZB7,Z19 says “There was this page where you could look up what to do in the, um,JNDI directory”. We considered the possibility of adding a concept such asremember_source of information to represent such utterances. This concept wouldreuse an existing (if rare) verb, but introduce a new object. The resulting
210 Chapter 22. Guidelines for modifying the base concept set
concept would be highly specialized, but that is also true of, for instance,explain_gap in knowledge. So why did we include explain_gap in knowledge in thebase concepts but did not, eventually, include remember_source of information?For two reasons: First, gap in knowledge concerns the subtle but importantdistinction of knowledge and meta-knowledge, while source of information isjust another type of fact knowledge. Second, we felt that moments of explain_gap in knowledge utterances are interesting, even crucial moments in a pairprogramming session, whereas remember_source of information is merely anotherform of tapping into resources – which pairs do all the time.
This does not mean that in your particular studies you should never addsomething like remember_source of information, but we think that entirely newconcepts should rarely be considered part of the base concept set but rather beconsidered part of a new layer. Separate layers will be discussed in Chapter 23.
Chapter 23Guidelines for creating newconcept sets
23.1 The idea of layers
As discussed in Section 1.4.3 (it might help to re-read that one-page sectionnow), the purpose of layers is modularizing the overall research process: Ratherthan inventing each concept yourself, you reuse one or several sets of conceptsthat are well-worn, refined, delineated, documented, minimized, and validated.
If all goes well, this has a number of advantages:
• Even though you may work with a large number of concepts, you canfind each concept easily because they come in clearly arranged topicblocks.
• For the same reason, you are less likely to misinterpret and abuse aconcept.
• You save a lot of concept development work, but grounding is still inplace, because constant comparison applies to reused concepts just like itdoes for your own.
• When you write up your results, you can do so more concisely, becauseyou may be able to refer to this book rather than explain everythingyourself in some places.
• If some other researcher concurrently reuses the same concepts as you, itwill be much easier to compare and combine the results afterwards.
211
212 Chapter 23. Guidelines for creating new concept sets
23.2 Granularity
To introduce successful concept layers for your own research questions, it maybe required to explain phenomena of a much larger or much smaller granularitythan those described by base concepts.
In some cases your research question may require (figuratively speaking) topull out a microscope to look at the local details of particular utterances. Inother cases, your research will want to understand larger-scale structures thatcomprise several utterances and help understanding the overall developmentof a pair programming session. For instance, some of the new concepts mayneed to talk about whole episodes (in the sense of Section 2.3.6) or about setsof such episodes.
23.3 Properties and property values
An example for a sort of finer-grained concept that may be useful for your layerare properties. Properties (and property values) relate to main concepts (andtheir annotation instances) somewhat like attributes (and their values) relate toclasses (and their instances): A property value annotation provides detail on aparticular instance of a concept.
Property concepts are a great way to add almost any detail you need regardingthe phenomena of an existing concept (whether a base concept or other). In par-ticular, adding such detail to existing concepts can be a useful intermediate stepwhen working towards identifying new concepts: Once you have enriched theexisting concept with enough detail, you may suddenly discover an expressivenew concept.
With respect to the base concepts, one use of this technique will apply whenyour research question requires differentiating a single base concept into severalnarrower concepts, in particular:
• Discriminating different “flavors” of an object type.
• Discriminating different “flavors” of a verb type.
For instance if you are interested in understanding how pair programmersdevelop the design of their software, you will need to record much more detailabout the design proposals, such as their granularity, the context in which theyarise, their focus (data, logic, structure, etc.), their newness relative to previousproposals of the same speaker, their newness relative to previous proposalsof the partner, their newness relative to existing code, the level of abstractionused to express them, the degree of detail given, and so on and so forth.
23.4. Forming “nice” layers 213
Also for verbs, there is no reason why for instance there could not be differenttypes or modes of challenging. The base layer description has already men-tioned two such verb subtypes for explanatory purposes: the agreement typesfor agree_finding (Section 12.2.9) and for agree_knowledge (Section 16.2.7) andthe proposal modes (Section 4.2.1) that apply to many concepts.
23.4 Forming “nice” layers
Obviously the advantages of layering will be damaged if the layers are toofine-grained, too coarse-grained, or their topic not well-defined. But how toobtain a right-grained and well-defined layer?
One could think about the problem of forming good layers in terms knownfrom software modularity: A nice layer would then have an interface thathides detail (meaning not all of the concepts will be explained in the articleyou eventually write about your study), it will have high coherence (meaningit focuses on a particular topic area), and it will strive for low coupling to otherlayers (meaning it does not meddle with the concepts of other layers more thannecessary, rather reusing them as they are when possible).
However, we do not know yet whether this metaphor is helpful. It may actuallystand in the way of focussing on what is most important, namely obtaininginsight with respect to your research question. “Nice” layers should probablybe considered a by-product of your pair programming research, not a goal inthemselves.
23.5 Go!
If you are one of those people who have to read the end of a book first even if itis a non-fiction book: Congratulations, you have now done so. Please proceedto Section 1.5.3, choose one of the two suggestions described there, and startreading in that manner.
If you have arrived here while following the suggestions of Section 1.5.31:Great, you are now ready to start your base-layer-driven research. Just goahead and complete your base layer knowledge as you go. Feel free to get incontact with us any time to discuss interesting phenomena you see or decisionsyou face. Maybe you also want to chat with us when defining your preciseresearch question? We will be glad to!
1If you have arrived here by reading this book cover-to-cover: Wow! You appear to be reallykeen on studying pair programming.
Bibliography
[1] E. Arisholm, H. Gallis, T. Dybå, and D. I. Sjøberg. Evaluating pair pro-gramming with respect to system complexity and programmer expertise.IEEE Transactions on Software Engineering, 33(2):65–86, 2007.
[2] K. Beck. Extreme Programming Explained: Embrace Change. Addison-WesleyProfessional, 1999.
[3] K. Beck and C. Andres. Extreme Programming Explained: Embrace Change,Second Edition. Addison-Wesley Professional, 2004.
[4] S. Bryant, P. Romero, and B. du Boulay. Pair programming and the myste-rious role of the navigator. International Journal of Human-Computer Studies,2008.
[5] L. Cao and P. Xu. Activity patterns of pair programming. In Proc. of the38th Annual Hawaii International Conf. on System Sciences (HICSS 2005),page 88a, Washington, DC, USA, 2005. IEEE Computer Society.
[6] J. Chong and T. Hurlbutt. The social dynamics of pair programming. InICSE07: Proceedings of the 29th Int’l Conf. on Software Engineering, pages354–363, Washington, DC, USA, 2007. IEEE Computer Society.
[7] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elementsof Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995.
[8] J. Hannay, T. Dybå, E. Arisholm, and D. Sjøberg. The effectiveness ofpair programming: A meta-analysis. Information and Software Technology,51(7):1110–1122, 2009.
[9] J. E. Hannay, E. Arisholm, H. Engvik, and D. I. K. Sjøberg. Effects of per-sonality on pair programming. IEEE Transactions on Software Engineering,36(1):61–80, Jan. 2010.
[10] J. T. Nosek. The case for collaborative programming. Communications ofthe ACM, 41(3):105–108, 1998.
[11] S. Salinger. Ein Rahmenwerk für die qualitative Analyse der Paarprogram-mierung. PhD thesis, Freie Universität Berlin, Fachbereich Mathematikund Informatik, 2013.
215
216 Bibliography
[12] S. Salinger, L. Plonka, and L. Prechelt. A coding scheme developmentmethodology using grounded theory for qualitative analysis of pair pro-gramming. Human Technology: An Interdisciplinary Journal on Humans inICT Environments, 4(1):9–25, 2008.
[13] S. Salinger, F. Zieris, and L. Prechelt. Liberating pair programming re-search from the oppressive driver/observer regime. In Proc. 35th Intl. Conf.on Software Engineering (ICSE), pages 1201–1204. IEEE Press, 2013.
[14] A. L. Strauss and J. M. Corbin. Basics of Qualitative Research: GroundedTheory Procedures and Techniques. SAGE, 1990.
[15] L. Williams and R. Kessler. Pair Programming Illuminated. Addison-WesleyProfessional, 2002.
[16] S. Wray. How pair programming really works. IEEE Software, 27(1):50–55,2010.
Index
Symbols*_design, 66*_step, 79, 130
Aactivity, 31, 32, 40activity, 40, 41, 46, 56, 67, 111, 151,
165, 169, 200agree_, 169, 171, 172, 174amend_, 169, 171–174challenge_, 169, 171–174disagree_, 118, 169, 171, 172, 174stop_, 169, 171, 173, 174think aloud_, 56, 166, 167, 169–
175, 183–189activity entity, 181advantage, 100agree, 41, 47–49, 64, 65, 67, 106, 145,
158, 161, 173, 204agree_activity, 169, 171, 172, 174agree_completion, 84agree_design, 60, 61, 64, 65, 81, 123,
124, 156, 161, 183agree_finding, 115, 120, 121, 123–128,
144, 156, 157, 183, 189, 202,203, 213
agree_gap in knowledge, 147–149agree_hypothesis, 133–135, 171, 186agree_knowledge, 102, 103, 120, 142,
148, 153, 155, 156, 158, 163,202, 213
agree_requirement, 70, 71agree_standard of knowledge, 148, 149agree_state, 97, 106agree_step, 75–78, 127, 157agree_strategy, 88, 96, 97, 99, 102, 103agree_todo, 88
agreement type, 127, 128, 155, 157,213
known, 127, 155me-too, 128unchecked, 155, 157understood, 128, 155
all is data, 27amend, 41, 47–49, 64, 78, 98, 123, 134,
148, 167, 173, 204amend_activity, 169, 171–174amend_design, 60–64, 80, 84, 89, 90,
101, 183, 202, 204amend_finding, 54, 115, 120, 122–125,
128, 129, 154, 157, 161amend_hypothesis, 133–136amend_knowledge, 154amend_requirement, 72amend_step, 63, 75–78, 82, 184, 204amend_strategy, 33, 63, 87, 88, 96–99annotation, 25, 30, 31, 37, 41, 46, 133,
182, 197, 199, see also dou-ble annotation
behavioristic ideal, 40memo, 77segmentation, 181shift-motivated, 203
ask, 38, 41, 47–49, 52, 81, 112, 114,161
ask_design, 60, 65, 67, 82ask_finding, 128, 129ask_knowledge, 55, 66, 67, 81, 82, 103,
119, 120, 122, 124, 128, 129,135, 140, 141, 144, 147, 148,152–154, 158, 159, 161–163,185, 187, 188, 206
ask_standard of knowledge, 55, 141ask_step, 75, 79, 82, 103, 140
217
218 Index
ask_strategy, 95, 96, 99, 103AT, 140, 141, 163attest_standard of knowledge, 142axial coding, 25
BBA1, 55, 59, 60, 63–65, 69, 70, 75, 78,
80, 83, 85, 95, 106, 117–119,121–123, 128, 132, 136, 140–144, 149, 152, 158, 160–162,168, 170–172, 183–185, 202,205
base concept, 23, 40style of definition, 198
base concept set, 23, 27, 35, 39, 207,see also coding scheme
and episodes, 40base layer, 23, 24, 27, 30, 31, 37, 95,
126, 181, 200and other layers, 211
base layer modification, 27, 30, 33,35, 37, 39, 41, 48, 49, 53,84, 85, 88, 95, 101, 102, 110,111, 114, 125, 128, 133, 137,148, 152, 157, 161, 162, 166,169–171, 173, 175, 181, 187,189, 190, 193, 198, 200, 201,203–205, 207–210
become_driver, 188, 193
CCA2, 59, 60, 63, 64, 66, 70, 75–77,
87, 89, 95, 96, 99, 102, 106,115, 117, 118, 125, 126, 132–134, 139, 140, 143, 152, 154,156, 159, 160, 162, 163, 166,172–174, 177, 187
can-check, 132category, 24challenge, 41, 47–49, 57, 64, 78, 98,
107, 125, 148, 167, 173, 200,204
challenge_activity, 169, 171–174challenge_completion, 84
challenge_design, 60, 62–64, 116, 123challenge_finding, 120, 122, 125–127,
129, 161, 200, 204challenge_hypothesis, 133, 134challenge_knowledge, 126, 153, 155–
158, 161challenge_requirement, 70, 71challenge_state, 105–107challenge_step, 63, 75, 77, 80, 82, 172challenge_strategy, 63, 96, 98, 99, 102code, 46coding scheme, 28, 35, 35, 207completion, 46, 47, 73, 83–85, 105,
167agree_, 84challenge_, 84disagree_, 84explain_, 56, 83–85, 107, 130, 172
completion/stateexplain_, 111
concept, 24, 25, 31concept category, 36
HCI/HEI, 36HHI, 36
concept class, 29, 36, 37, 202facade concepts, 37for HCI/HEI concepts, 36
concept name, 45constant comparison, 25constructive concept, 49context, 25, 37, 38, 59, 61, 62, 76, 90,
120, 128, 137, 182, 197, 199,205
DD, 114, 115, 117, 189DC, 115, 118decide, 41, 47–49, 64decide_design, 60, 64, 89decide_step, 75, 78decide_strategy, 96, 99, 102design, 46, 56, 59, 60, 65–67, 73, 74,
76, 78, 79, 82, 85, 89–91, 94,99, 101, 122, 161, 181
Index 219
*_, 66agree_, 60, 61, 64, 65, 81, 123,
124, 156, 161, 183amend_, 60–64, 80, 84, 89, 90,
101, 183, 202, 204ask_, 60, 65, 67, 82challenge_, 60, 62–64, 116, 123decide_, 60, 64, 89disagree_, 60, 64, 66, 155, 161explain_, 56justify_, 152propose_, 53–56, 59–64, 66, 67,
71, 72, 75, 77, 79, 80, 84, 90,91, 101, 115, 122, 123, 130,152, 155, 156, 159, 166, 167,172, 173, 202, 203, 206
design/requirement/step/strategy/todopropose_, 111
dimensionalization, 25disagree, 41, 47–49, 57, 65, 67, 78, 80,
125, 127, 145, 148, 158, 161,173, 204, 209
disagree_activity, 118, 169, 171, 172,174
disagree_completion, 84disagree_design, 60, 64, 66, 155, 161disagree_finding, 120, 125, 129, 144,
161, 187disagree_hypothesis, 133, 134disagree_knowledge, 153, 156–158disagree_requirement, 72disagree_step, 33, 40, 75, 78, 82, 88,
105, 106, 155disagree_strategy, 88, 96, 98, 99disagree_todo, 209DO, 115, 118, 154do, 181, 182do_sth, 168, 169, 172, 185, 187, 188,
190, 198doing, 36double annotation, 67, 79, 90, 102,
107, 112, 114, 126, 143, 159–161, 163, 165, 193, 199, 200
doubted, 131, 133
DPR, 93–95, 97, 99, 100driver
become_, 188, 193DU, 114, 115, 117–119, 122
Eearly repetition, 203, 204episode, 40, 41, 62, 128, 201, see also
exampleshift, 203
example, 55, 59–62, 65–66, 69–71,74–81, 83–84, 87–89, 95–97,102–103, 105–106, 115–120,122–129, 134–136, 141–142,152–157, 162–163, 171–173,182–189, 202
for ostensive definition, 28reference to, 28, 33, 41, 56, 60,
62–64, 67, 70, 71, 76–79, 81,84, 85, 89, 90, 96–99, 101,102, 106, 117, 125, 128, 130,134, 141–144, 154–158, 161–163, 171–174, 181, 190, 200–202, 204–206
explain, 47–49, 56, 57, 123, 133, 136,199, 200
explain_completion, 56, 83–85, 107,130, 172
explain_completion/state, 111explain_design, 56explain_finding, 55, 64–66, 72, 74–76,
78, 79, 82, 85, 89, 90, 99,107, 112, 115, 117–128, 130,133, 134, 136, 137, 140, 145,157, 159–162, 183–189, 199,202–204
explain_gap in knowledge, 112, 147–149, 210
explain_hypothesis, 134explain_knowledge, 30, 33, 53–56, 64,
66, 67, 71, 72, 74, 76, 79, 82,85, 87–90, 96, 99, 102, 103,111, 112, 114, 120, 121, 125,133, 135, 136, 140–142, 147,
220 Index
152–163, 167, 174, 188, 199,202, 204, 209
explain_responsibility, 152explain_standard of knowledge, 61, 97,
102, 112, 113, 121, 128, 135,139–145, 148, 149, 155, 156,162, 163, 167, 172
explain_state, 56, 97, 105–107, 130,209
explain_step, 48explore, 181, 182explore_sth, 171, 173, 185–187, 190,
198EXS, 93, 94, 97, 99
Ffacade concept class, 165facade concepts, 37finding, 113finding, 46, 52, 54–56, 66, 77, 79, 99,
110, 111, 113–120, 122, 123,125, 126, 128–130, 136, 142,144, 151, 153, 154, 159–161,167, 168, 200, 207
agree_, 115, 120, 121, 123–128,144, 156, 157, 183, 189, 202,203, 213
amend_, 54, 115, 120, 122–125,128, 129, 154, 157, 161
ask_, 128, 129challenge_, 120, 122, 125–127, 129,
161, 200, 204disagree_, 120, 125, 129, 144, 161,
187explain_, 55, 64–66, 72, 74–76,
78, 79, 82, 85, 89, 90, 99,107, 112, 115, 117–128, 130,133, 134, 136, 137, 140, 145,157, 159–162, 183–189, 199,202–204
finding type, 114–119, 122, 154, 157,160, 184, 189
D, 114, 115, 117, 189DC, 115, 118
DO, 115, 118, 154DU, 114, 115, 117–119, 122P, 114, 117–119T, 116, 117TB, 116, 118TC, 116, 118, 119, 157, 160, 184TU, 116, 160
findings, 125forcing, 25, 25, 26, 27
Ggap in information, 117gap in knowledge, 46, 110, 111, 113,
139, 147, 148, 210agree_, 147–149explain_, 112, 147–149, 210
gap of knowledge, 47gibberish, 177grounded theory, 26grounding, 24, 25, 28, 39, 48, 53, 69
Hhard-to-verify, 131, 132hypothesis, 46, 54, 56, 110, 111, 113,
128, 131–133, 136, 144, 159,161
agree_, 133–135, 171, 186amend_, 133–136challenge_, 133, 134disagree_, 133, 134explain_, 134propose_, 99, 102, 111, 133–136,
145, 158, 161, 162, 171, 185,186, 202, 203
hypothesis type, 131–133can-check, 132doubted, 131, 133hard-to-verify, 131, 132
Iillocution, 27, 31, 39, 49, 66, 152, 154,
197, 209and intention, 38
Index 221
behavioristic ideal, 40for activities, 198indirect speech act, 63of justifications, 204primary and secondary, 63, 82,
199illocutionary act, 38immediate repetition, 203implicit action announcement, 201initiative verb, 49intention, see illocutioninterrupt
react to_, 194issue type, 132
Jjustification, 204justification, 204justify, 152justify_design, 152
Kknowledge, 109knowledge, 46, 48, 52–54, 56, 64, 66,
67, 79, 99, 111, 113, 114,116, 117, 122, 130, 136, 144,148, 151–154, 159, 160, 168,207, 209
agree_, 102, 103, 120, 142, 148,153, 155, 156, 158, 163, 202,213
amend_, 154ask_, 55, 66, 67, 81, 82, 103, 119,
120, 122, 124, 128, 129, 135,140, 141, 144, 147, 148, 152–154, 158, 159, 161–163, 185,187, 188, 206
challenge_, 126, 153, 155–158, 161disagree_, 153, 156–158explain_, 30, 33, 53–56, 64, 66,
67, 71, 72, 74, 76, 79, 82, 85,87–90, 96, 99, 102, 103, 111,112, 114, 120, 121, 125, 133,
135, 136, 140–142, 147, 152–163, 167, 174, 188, 199, 202,204, 209
known, 127, 155
Llater repetition, 204layers, 211LO, 63, 66, 76, 102
Mme-too, 128memo, 25mumble, 47–49mumble_sth, 49, 61, 62, 115, 124, 135,
142, 173, 177, 188
Oobject, 46, 209OE, 63, 64, 96off topic, 47, 48
say_, 49, 177, 184open coding, 25OWP, 93–95, 97–99, 101OWS, 97
PP, 114, 117–119P&P concepts, 37, 50, 57, 110, 152,
158, 161pair coding, 26paraphrasing, 134, 141, 142, 149, 162,
205, 206PI, 63, 64, 96primary characterizing attribute, 28,
35, 116, 128, 202, 209, seealso property
agreement type, 127, 128, 155,157, 213
finding type, 114–119, 122, 154,157, 160, 184, 189
hypothesis type, 131–133proposal mode, 63, 64, 66, 76,
96, 102, 213
222 Index
standard of knowledge utter-ance type, 139–141, 153, 163
strategy type, 93–95, 97–101think aloud topic, 167–169
primary intention, 38property, 25, 28, 90, 94, 132, 152, 161,
209, 212, see also primarycharacterizing attribute
proposal mode, 63, 64, 66, 76, 96,102, 213
LO, 63, 66, 76, 102OE, 63, 64, 96PI, 63, 64, 96
propose, 38, 41, 47–49, 56, 57, 64, 72,81, 96, 98, 107, 126, 133,201
propose_design, 53–56, 59–64, 66, 67,71, 72, 75, 77, 79, 80, 84, 90,91, 101, 115, 122, 123, 130,152, 155, 156, 159, 166, 167,172, 173, 202, 203, 206
propose_design/requirement/step/strate-gy/todo, 111
propose_hypothesis, 99, 102, 111, 133–136, 145, 158, 161, 162, 171,185, 186, 202, 203
propose_requirement, 69–72propose_step, 40, 56, 61, 63, 67, 75–82,
89, 90, 95, 100, 101, 105–107, 115, 119, 123, 124, 126,127, 130, 134, 143, 148, 149,154, 159, 167, 171, 172, 184,186, 187, 189, 200
propose_strategy, 56, 63, 90, 95–97,99–102
propose_todo, 67, 87–90, 97, 99, 107proposed_step, 80propse_step, 174PT, 139PTd, 139PTe, 140PTo, 140, 153
R
react to_interrupt, 194reactive verb, 49read, 181, 182read_sth, 185, 189remember, 48, 49, 71remember_requirement, 70–72, 111remember_source of information, 209,
210remind, 72remind_requirement, 71, 72requirement, 47, 56, 69–71, 73, 74
agree_, 70, 71amend_, 72challenge_, 70, 71disagree_, 72propose_, 69–72remember_, 70–72, 111remind_, 71, 72
requirements, 60, 69responsibility
explain_, 152RT, 140
Ssay, 48, 49say_off topic, 49, 177, 184saying, 36search, 181, 182search_sth, 183–185, 194, 198selective coding, 26Session
BA1, 55, 59, 60, 63–65, 69, 70,75, 78, 80, 83, 85, 95, 106,117–119, 121–123, 128, 132,136, 140–144, 149, 152, 158,160–162, 168, 170–172, 183–185, 202, 205
CA2, 59, 60, 63, 64, 66, 70, 75–77, 87, 89, 95, 96, 99, 102,106, 115, 117, 118, 125, 126,132–134, 139, 140, 143, 152,154, 156, 159, 160, 162, 163,166, 172–174, 177, 187
Index 223
ZB7, 59, 79, 94, 95, 105, 126, 132,133, 135, 147, 185, 209
shift, 202show, 181, 182show_sth, 184, 189–191sketch, 181, 182sketch_sth, 189, 191something, 47, 181source of information, 210
remember_, 209, 210standard of knowledge, 46, 47, 52, 54,
110, 111, 113, 139, 141, 142,147, 148, 151
agree_, 148, 149ask_, 55, 141attest_, 142explain_, 61, 97, 102, 112, 113,
121, 128, 135, 139–145, 148,149, 155, 156, 162, 163, 167,172
standard of knowledge utterancetype, 139–141, 153, 163
AT, 140, 141, 163PT, 139PTd, 139PTe, 140PTo, 140, 153RT, 140
state, 46, 47, 73, 83, 85, 105, 106agree_, 97, 106challenge_, 105–107explain_, 56, 97, 105–107, 130,
209step, 40, 46, 47, 56, 63, 67, 73–76, 79,
81–83, 85, 87–90, 93, 94, 96,99–101, 105, 107, 130, 181
*_, 79, 130agree_, 75–78, 127, 157amend_, 63, 75–78, 82, 184, 204ask_, 75, 79, 82, 103, 140challenge_, 63, 75, 77, 80, 82, 172decide_, 75, 78disagree_, 33, 40, 75, 78, 82, 88,
105, 106, 155
explain_, 48propose_, 40, 56, 61, 63, 67, 75–
82, 89, 90, 95, 100, 101, 105–107, 115, 119, 123, 124, 126,127, 130, 134, 143, 148, 149,154, 159, 167, 171, 172, 184,186, 187, 189, 200
proposed_, 80propse_, 174
step with strategic character, 100sth, 36, 47, 48, 181
do_, 168, 169, 172, 185, 187, 188,190, 198
explore_, 171, 173, 185–187, 190,198
mumble_, 49, 61, 62, 115, 124,135, 142, 173, 177, 188
read_, 185, 189search_, 183–185, 194, 198show_, 184, 189–191sketch_, 189, 191verify_, 117, 169, 170, 185–187,
189–191, 194, 198wait for_, 194work alone_, 193work in parallel_, 193write_, 166, 168, 172, 173, 182,
183, 187, 191stop, 48, 49stop_activity, 169, 171, 173, 174strategy, 35, 40, 47, 56, 63, 64, 67,
73, 74, 76, 79, 83, 85, 87, 89,90, 93–96, 98–101, 105–107,167, 208
agree_, 88, 96, 97, 99, 102, 103amend_, 33, 63, 87, 88, 96–99ask_, 95, 96, 99, 103challenge_, 63, 96, 98, 99, 102decide_, 96, 99, 102disagree_, 88, 96, 98, 99propose_, 56, 63, 90, 95–97, 99–
102strategy type, 93–95, 97–101
DPR, 93–95, 97, 99, 100
224 Index
EXS, 93, 94, 97, 99OWP, 93–95, 97–99, 101OWS, 97
TT, 116, 117TA1, 167, 168TA10, 167, 168TA11, 168TA2, 167, 168TA3, 167, 169TA4, 167–169TA5, 167, 169TA6, 167–169TA7, 167, 169TA8, 167TA9, 167TB, 116, 118TC, 116, 118, 119, 157, 160, 184thematic shift, 202theoretical coding, 25theoretical sampling, 25, 26theoretical saturation, 26theoretical sensitivity, 25theory, 24Think, 33, 90, 98, 103, 111, 113, 145,
158, 160, 162, 165, 170, 181,185, 187, 190, 191, 197, 198,204, 205
think aloud, 48, 49, 56think aloud topic, 167–169
TA1, 167, 168TA10, 167, 168TA11, 168TA2, 167, 168TA3, 167, 169TA4, 167–169TA5, 167, 169TA6, 167–169TA7, 167, 169TA8, 167TA9, 167
think aloud_activity, 56, 166, 167, 169–175, 183–189
todo, 47, 56, 67, 73, 74, 79, 87–90, 209agree_, 88disagree_, 209propose_, 67, 87–90, 97, 99, 107
topic, see episodetranscription markup, 31TU, 116, 160
Uunchecked, 155, 157understood, 128, 155universal concepts, 111utterance, 31, 39, 40
on activity, 165reply, 49segmentation, 200transcription markup, 31vs. the thing itself, 40
Vverb, 47, 49, 209
bivalent, 49constructive, 49initiative, 197reactive, 198unconstructive, 49
verify, 181, 182verify_sth, 117, 169, 170, 185–187,
189–191, 194, 198
Wwait for_sth, 194work alone_sth, 193work in parallel_sth, 193write, 181, 182write_sth, 166, 168, 172, 173, 182,
183, 187, 191
ZZB7, 59, 79, 94, 95, 105, 126, 132, 133,
135, 147, 185, 209
UnderstandingqP
airqProgra
mm
ing:qT
heqBaseqLa
yerS
tephanqS
alingerq•qLutzqP
rechelt
StephanqSalingerq•qLutzqPrechelt
UnderstandingqPairqProgramming:
TheqBaseqLayerThereq hasq beenq andq stillq isq aq lotq ofq controversyq onq whetherq pairqprogrammingqisqaqusefulqengineeringqtechniqueq–qasqifqthisqwouldqnotqstronglyqdependqonqtheqspecificqgoals,qtask,qandqtheqpair-sqpairqprogrammingq skill.q Ratherq thanq providingq stillq moreq bottom-line,qquantitativeq resultsq onq pairq programming,q aq researchq groupq atqFreieqUniversitätqBerlinqsetqoutqtoqdecipher
–qwhatqisqtheqactualqprocessqofqpairqprogrammingqand
–qwhatqisqpairqprogrammingqskill.
Thisq bookq providesq aq setq ofq conceptsq thatq servesq asq theqinfrastructureq forq studiesq ofq pairq programmingq thatq focusq onqqualitativeq dataq analysis.q q Itq promisesq toq connectq theq resultsq ofqsuchqstudiesqtoqoneqanother.
Theq bookq isq orientedq towardsq researchersq only,q notq towardsqpractitioners.
StephanqSalingerq•qLutzqPrechelt
UnderstandingqPairqProgramming:qTheqBaseqLayer
9 783732 281930
Recommended
