May 15, 2018 - Mob programming in a small development team has ..... efits of releasing a less flawed and more customer satisfying product .... According to Boyatzis (1998): to properly encode the data, the ... An agile development process divided into sprints, which are ...... Or at least fix to accessor is right, because.
Ole Kristian Aune Christian Hans-Pieter Kat Echtermeyer Elias Brattli Sørensen
Mob Programming: A Qualitative Study from the Perspective of a Development Team
Bachelor thesis Trondheim, May 23, 2018 Department of Applied Informatics (AIT) Norwegian University of Science and Technology (NTNU)
Supervisor: Assistant Professor Nils Tesdal
NTNU Norwegian University of Science and Technology
Bachelor thesis for the degree of Computer Engineer
Department of Applied Informatics (AIT)
© 2018 Ole Kristian Aune, Christian Hans-Pieter Kat Echtermeyer and Elias Brattli Sørensen.
i
Abstract Mob programming is a relatively new and unexplored development method. As a result the research is sparse on how it is experienced by developers. Several publications on mob programming describe the experiences of the team leader and change in productivity. There are also mentions of the effects on the individual developer, but there is little research done on this topic. The focus of this study is to find benefits and risk of mob programming, by observing interactions within a three man mob and how it influences the developers. This was achieved by collecting qualitative data through diaries, retrospective meetings and video footage during a four month development project creating a web-based system. The data was then analyzed using thematic analysis. The results show that potential benefits of mob programming are increased productivity on certain tasks, improved problem solving and code quality, and developer enjoyment and motivation. The risks found are bad cooperation, fatigue and bad timing of role switching. Several benefits and risks appear to be similar to those of pair programming. The insights and hypotheses found in this report may contribute to further research on the topic.
iii
Summary and Conclusions In software development, mob programming is a relatively new and unexplored method. The research on the method is therefore limited. Several publications on mob programming describe the experiences of the team leader and change in productivity, but there are few insights on the effects on the individual developer. The focus of this report is to find benefits and risks of mob programming, by observing how the developers interact with each other and are influenced by the method. Because mob programming and pair programming have similarities, publications on pair programming may be relevant. From previous publications about pair programming and mob programming, mob programming is believed to have benefits related to: Code quality, problem solving, continuous code reviews, focus, communication and learning. It is also believed to have risks related to: Organizational culture, dominant personalities and fatigue and ergonomics. The experiment was conducted by collecting qualitative data through diaries, retrospective meetings and video footage, and analyzing it using thematic analysis. Mob programming in a small development team has both advantages and disadvantages, many of which were discovered to be similar to pair programming. The main benefits can be found when developers are making critical parts of a system, in strengthening code quality and in transfer of knowledge. Mob programming appears to work well for developing good solutions to critical and complex parts of a system, yet slow at parts that are repetitive and easy. One of the main potentials of mob programming appears to be the transfer of knowledge between team members. Programming with others seems to nurture good programming habits including formatting, design patterns, tool usage and other small details related to programming languages. Such knowledge may not be acquired from a supervisor or teacher, but is rather likely to be passed from student to student. The developers were observed several times expressing enjoyment of new found knowledge throughout the development. There were also occasions with fatigue and annoyance. Annoyance generally arose when there was bad communication, bad cooperation or the team was fatigued and tired. This research was conducted during the development of a stand alone web-application in cooperation with the Norwegian Roads Administration and the IT consulting firm Kantega. The research was done on a developer team of three students with limited development experience. These findings may be of interest to anyone looking to try mob programming and for further research on this subject.
Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
i
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ii
Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
iii
List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii List of Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii 1 Introduction
1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2 The Development Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2.1 Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
1.2.2 Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.2.3 The developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.3 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
1.4 Structure of the Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2 Background
5
2.1 Literature Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1 Mob programming explained . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.2 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.3 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.1.4 Remaining work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
2.2 Thematic Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
3 Approach
11
3.1 Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
iv
CONTENTS
v
3.3 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.3.1 Details . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
14
3.4 Summary of Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4 Results
17
4.1 Results first analysis iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.2 Final results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.2.1 Learning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.2.2 Team Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.3 Software Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.2.4 Personal Dynamics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
28
5 Discussion
32
5.1 First analysis iteration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.2 General Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
5.3.1 Data collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.3.2 Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
5.4 Other Observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.4.1 Focus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.4.2 Code Produced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
5.4.3 Work environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
6 Conclusion
38
6.1 Summary and Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
6.1.1 Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
6.1.2 Risks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
6.1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.2 Further Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
6.2.1 Further research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
Bibliography
40
A Acronyms
43
CONTENTS
vi
B Terms
44
C Themes from analysis
45
List of Figures
1.1 Workstation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3.1 Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15
4.1 Initial Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4.2 Final Themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
4.3 A plan for a work day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
30
List of Tables
4.1 Initial main themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
4.2 Themes and sub-themes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
19
5.1 Code Produced . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
vii
Chapter 1 Introduction 1.1 Background The basis for for the project was a request from Kantega to investigate the development method mob programming. Because the method is based on using the entire team on one task at a time, it is difficult to justify this approach towards a paying customer over a traditional method where every developer works separately. Therefore we, as students, had an unique opportunity to investigate potential benefits and drawbacks in this methodology without economic risk. During this study, a team of three developers were working mainly on one computer, supported by two other computers providing problem solving stations where developers can search for solutions. The purpose of this report is to explore the benefits and risks of mob programming through a qualitative study.
Problem Formulation This is an attempt from a small team of novice developers to explore mob programming in a qualitative study. Because the study is of qualitative nature, it should only be used as advice and comparison by others, especially considering mob programming is a relatively new and unexplored method. The research data was collected during the period of development from January to May 2018. This study could be of interest to others looking into exploring mob programming, either for research purposes or for attempting to practice it.
1
CHAPTER 1. INTRODUCTION
2
1.2 The Development Project The assignment was a software development project for the Norwegian Public Roads Administration (Norwegian Public Roads Administration (2018)). The product created is a webbased tool for receiving and handling inspection reports, as well as creating cases for improvement of the road network, which can be forwarded to contractors or other relevant parties. It is a standalone system with its own database, and integration with the National Roads Database, built with Docker (Docker (2018)). It has support for image URLs and map views, with front-end in React and Redux (Caspers (2017)), and a REST back-end in Java. It is also possible to connect to a login service. The main focus during the development has been to make an Application Programming Interface (API) for report and case management integrating with the Roads Administration’s ecosystem.
1.2.1 Workstation
Figure 1.1: The work environment setup. Three developers sit on one side of a long table with their individual computers. A large screen is showing the main work activities, connected to one of the computers. When working intensively over a long period of time it is important to make the workspace as comfortable as possible. It is also important to follow the main ideas mob programming, described by Zuill and Meadows (2016), to conduct realistic research. This resulted in the
CHAPTER 1. INTRODUCTION
3
setup of the work environment seen in Figure 1.1. The three developers sit on one side of a long table with their individual computers. A large screen showing the programming is placed in front so everyone can view their own computer and the screen. Behind the seats is a whiteboard containing notes, plans and any other relevant information. The room is located slightly isolated with doors in between so that there is little sound disturbance.
1.2.2 Timer A timer is a recommended tool in mob programming. The timer is a computer application set to alert at specified intervals. Since there is only one person typing at any given time it is important to switch often, so that every participant stays focused. By having a fair system, everyone gets equal amounts of time on each role. Therefore a timer was used in the beginning. Throughout the project several different timer settings were tested trying to find the one that worked best for the team. It started with 10 minutes with a 1 minute switching time between, as recommended by Boekhout (2016). It turned out rather annoying and disturbing after a few days, as the 1 minute switch time was not enough to finish up the current task. After that the next setup was 7 minutes work time with a 3 minute switching time. With a longer switch time, after the clock indicating that it is time to switch, the current driver has 3 minutes to finish up his task when he is in the flow. Lastly the timer was cut completely, because it was more annoying than it contributed. The report comes back to this topic in Chapter 4, as part of the analysis.
1.2.3 The developers The team consists of three novice developers in the same field of study. The developers are good friends and have known each other for nearly three years. They have previously worked on several projects together. None of the members are considered to have a too dominant personality. The team members were 21-23 years of age during the time of the study.
1.3 Objectives The main objectives are to identify potential benefits and risks of the method of mob programming, and match observations with other already identified features. Another goal is to contribute to lay a foundation for further research on the topic.
CHAPTER 1. INTRODUCTION
4
1.4 Structure of the Report The rest of the report is structured as follows. Chapter 2 contains theoretical background and a literature review relevant to the study. Chapter 3 shows the approach used in the study while Chapter 4 contains the results that emerged from the thematic analysis. The results are discussed in Chapter 5, while Chapter 6 contains the summary, recommendations for further work and the conclusion.
Chapter 2 Background 2.1 Literature Survey 2.1.1 Mob programming explained Mob programming, or "mobbing" is as described by Woody Zuill and Kevin Meadows (Zuill and Meadows, 2016, p. 2), "a software development approach where the whole team works on the same thing, at the same time, in the same space, and at the same computer." When a team consist of more than two developers working on one task, it is considered a "mob". It is recommended to use the Driver/Navigator model, which is a common way to practice pair programming. According to Williams et al. (2000), the driver is the person typing or implementing the next feature, while the navigator has several tasks; inspection of the code being typed, strategic thinking for what to implement next, looking up solutions. The roles are switched often, such that both developers have manned the role of driver multiple times during a session. The extension in the case of mob programming is that there are several navigators, that with their combined knowledge guide the driver towards the goal. Zuill and Meadows (2016) describes that an important part of cooperation is to make sure the navigators give instructions at the correct level of abstraction. This means that if the driver knows what he is doing, navigate at a more strategical level. If the current implementation is difficult, navigate on a code line or statement level if necessary. It is however observed by Chong and Hurlbutt (2007) that in pairs where the developers have a similar level expertise, the roles are rather difficult to distinguish. Instead of one person guiding the other, both work at an equal level, working in unity on each task discussing
5
CHAPTER 2. BACKGROUND
6
the matter at hand. The programmers jointly take the roles of both driver and navigator, regardless which one of them possesses the keyboard. Thus the only thing separating roles is the task of typing.
2.1.2 Benefits One of the ideas behind pair programming, which is also relevant in mob programming, is that two heads are better than one. Thus when solving complex tasks, a team of developers focusing on the same task are more suited for producing a well-designed solution than a single developer. There are several studies of pair programming (Williams et al. (2000), Cockburn and Williams (2001)) confirming this idea. Because there are similarities between the methodologies, this section is largely based on the more researched method of pair programming. In a conversation with Torgeir Dingsøyr (Dingsøyr, T. (2018)), it was suggested that the background from pair programming might be transferable to the practice of mobbing. Pair programming is believed to have the following benefits: Code quality, problem solving, continuous code reviews, focus, communication and learning.
Code quality As suggested by previous research on pair programming (Williams et al. (2000)), both overall productivity and the quality of the work is increased when programming in pairs. The benefits of releasing a less flawed and more customer satisfying product outweighs the costs of increased programming hours. A less flawed product also implies lower maintenance costs. The study finds that developers programming in pairs are able to make designs superior to their solo peers. This was indicated by the pairs producing shorter and more maintainable programs, when solving the same task as their peers. Also Cockburn and Williams (2001) find that designs are better and programs shorter when pair programming. This trend is also recognized in the field of mob programming because of the many eyes constantly reviewing the code quality, according to publications on the subject (Balijepally et al. (2017) and Zuill and Meadows (2016)).
Problem solving Collaboration improves problem solving, and it is shown by Williams et al. (2000) that pairs can solve complex tasks more easily. Other research (Cockburn and Williams (2001)) con-
CHAPTER 2. BACKGROUND
7
firms this statement, describing that pairs share their knowledge and energy to tackle puzzling problems by alternating who leads the way. This leads to reduced time spent on debugging and testing. Wilson (2015) confirms this as a possible advantage in mob programming, describing that a mob is beneficial for solving complex tasks.
Continuous code reviews It is shown by Cockburn and Williams (2001) that defects in the code are found earlier because of the continuous code review in pair programming. Traditional reviews or inspections were introduced as a cost-effective way to discover and remove defects as early as possible. Reviews often result in a demand for code changes or refactoring, which means the developer has to dive back into their work. After correcting the error, they have to wait for another review before they can merge their work and call it done. In the case of pair programming, the error might instead be found immediately while being typed. This implies a more efficient review process, and also allows the programmer to escape the often distasteful and annoying reviews after the work is done. Also in the case of mob Programming, it is confirmed by Zuill and Meadows (2016) that a mob reviewing the code being written, leads to lower need for refactoring after development.
Focus Another promising factor found by Williams et al. (2000) is the commitment the programmer has to their partner when pair programming. The pairs put a mutual pressure on each other, and the full focus and concentration of both driver and navigator is needed for the pair programming to work smoothly. The research also finds it less likely that the programmers spend time on unrelated activities while under the gaze of their coworker, compared to when working on their own. Because of the team’s common focus on the task, pair programmers usually work with greater intensity and motivation than individual developers. It is also suggested by other sources (Cockburn and Williams (2001) and Aref et al. (2013)) that developers find working in pairs more enjoyable than working on their own. As shown by publication on mob programming (Balijepally et al., 2017, p. 6)), the peer pressure and team focus also applies there.
CHAPTER 2. BACKGROUND
8
Communication Cockburn and Williams (2001) imply that, when pair programming, information flows faster as team members communicate more easily and more often. It is also shown by (Balijepally et al., 2017, p. 4) that improved communication is a clear advantage in mob programming, because the wait time for correct information is reduced. Mob programming reduces the time a developer is blocked from moving on with their work, because they wait for a piece of information or a clarification. This is because the developer probably has access to the answer within the mob.
Learning The publication by Cockburn and Williams (2001) indicates that when working closely together on the same task, knowledge is passed between partners. This could be routines of tool usage, design patterns, rules related to programming languages and formatting. These learning patterns are confirmed by Zuill and Meadows (2016) in their book about mob programming. In a situation when all developers in a team bring their own set of skills to the table, there are many possibilities of learning. The use of Pair Programming could also be useful when teaching programming courses because students can teach each other details not taught directly by supervisors or instructors.
2.1.3 Risks There are several risks that both pair- and mob programming have in common. The first impression of both methods might be that they seem wasteful. Two or several more "resources" are spent on one task, a task that could be completed by a single person. Previous publications exploring pair programming (Cockburn and Williams (2001), Williams et al. (2000)) have found there to be a certain development-time cost in collaborative development. According to Balijepally et al. (2017), there are several possible risks related to mob programming: Organizational culture, dominant personalities and fatigue and ergonomics.
Organizational culture Since mob programming usually consists of a team of experts, ideally they need to be able to make decisions and be self-organized. If the team exists within an organization with leaders
CHAPTER 2. BACKGROUND
9
that like to micromanage and operate by a top-down decision making model, a mob might feel like their hands are tied. Their productivity will be seriously affected if the team constantly has to wait for external stakeholders to make decisions. Ideally, the decision-making stakeholder is a part of the mob, easily providing decisions and answers on the go.
Dominant personalities A clearly dominant member of the team could disrupt the balance of the team. Having one or a few of the people on the team making all the decisions and doing all the talking might make certain members of the team feel like they are unable to participate. For a mob team to work well, Zuill and Meadows (2016) states that the team members need to treat each other with kindness, respect and consideration to keep the working atmosphere at a sane level. Such a risk also applies to pair programming, where Williams et al. (2000) found issues related to developers working with certain partners possessing a rather excessive ego. The same issue was found when it was the other way around, with a developer unable to contribute. There are also observations done by Chong and Hurlbutt (2007) and Aref et al. (2013) regarding issues with having a pair in which the level of skill is largely different. The tendency is that the more experienced programmer dominates the session.
Fatigue and Ergonomics To be able to work closely together with other developers, the setup of the work space becomes critical. There are demands having comfortable chairs, large monitors, whiteboards, maybe multiple keyboards and so on. The team also needs an office space in which they can communicate without interruption, and not disturbe co-workers with the noise from discussions. Mob programming can, like pair programming become quite intensive. This also renders demand for periodic, organized breaks, and scheduled time for letting the members complete their individual tasks (eg. time sheets, emails, attending unrelated meetings and so on).
2.1.4 Remaining work Even though there have been several empirical studies finding clear benefits of pair programming, and a few teams have tried mob programming in the last few years, there has
CHAPTER 2. BACKGROUND
10
not yet been done consistent research regarding the strengths and weaknesses of mob programming. There still needs to be done empirical studies with well controlled experiments, exploring advantages and other factors of the method. To know what to look for, it is also desired to identify hypotheses and theories through qualitative studies.
2.2 Thematic Analysis The approach used in this report was thematic analysis, which is a common method to analyze qualitative data in several fields of research (Boyatzis, 1998, p.6). Thematic analysis is "a method for identifying, analyzing and reporting patterns (themes) within data" (Braun and Clarke, 2006, p. 79). Data may in this case be a transcript of an interview, a set of journals or any other form of semi- or unstructured conversation. A theme captures something important about the data in relation to a research question, and may be theory-driven or data-driven. A theory-driven theme has background in existing theory, while a data-driven theme is found based on the contents of the data. The analysis is a process being used as a part of other qualitative methods. It is not defined as a separate method itself, but rather a tool to gain insight into a subject. The process of thematic analysis is made for encoding qualitative data. According to Boyatzis (1998): to properly encode the data, the researcher needs an explicit code. The code might be several different things. Indicators, a list of themes, or casually related qualifications. Several codes may together form a theme, or a code may become at theme itself (Braun and Clarke (2006)). It is an iterative analytical process, where the analyzer follows a certain set of steps, possibly repeating steps if needed, to refine the analysis. The steps in the process are described in Chapter 3.3.
Chapter 3 Approach 3.1 Software Development Mob programming was first practiced for 2.5 months. Then followed one month of pair programming, so that the analysis could begin (the team switched between pair programming, and writing). The last two weeks were based on mob programming again, though not every day. This resulted in approximately 3 months of mob programming. The amount of days spent coding was approximated to 45 days over that period. An agile development process divided into sprints, which are visually represented in Figure 3.1, was followed. A sprint is a short period of a few weeks where the team produces a visible, usable, deliverable product that implements one or more user interactions with the system. The main goal of each sprint is to deliver valuable functionality (Rising and Janoff (2000)).
3.2 Data collection Data was collected in three different ways as advised by Professor of Psychology, Laumann, K. (2018); daily diaries, daily retrospective meetings in the end of each day and video tapes of the work sessions. In the diaries the goal was to give a work summary and then summarize impressions or feelings. The length of the diaries was typically 1-2 paragraphs. The retrospective meetings had an agenda of answering the following questions: 1. What went well? 2. What could have been better?
11
CHAPTER 3. APPROACH
12
3. How could we improve this? The videotapes were taken from the beginning of the day, and captured 7 hours of the day before the camera storage was full. Early in the process, the team also answered a survey in the beginning of each day, rating the overall mood. This was to avoid the possibility that having a bad day would influence the view of the method, and give an incorrect perception of the experiences. However, after a few weeks the value of the surveys was reevaluated, and the surveys were discarded. It was figured that a simple rating of how you feel (a scale of 1 to 5) is more of a quantitative data field, and irrelevant to a qualitative study. Also, it was considered difficult to properly rate how you feel by a simple number. Therefore, the main focus was collecting diaries, daily retrospectives and video material. In addition to these evenly distributed data sets, the team also had retrospective meetings every second week, evaluating and readjusting the process based on the experiences of the previous sprint. The diaries were always written before the retrospective meetings were held, to avoid the subjects from influencing each others views. Approximately 180 hours of video footage was taken during the development. The observations of the software development the team in this study might be similar to observations of a focus group, a collection of people gathered in order to discuss a particular subject, in that way solving an issue. To transcribe focus groups in an unstructured environment is, according to Gill et al. (2008), time consuming. It might take up to 8 hours to transcribe 1 hour of data. To review such an amount of footage might therefore require more than 1000 work hours, which was impossible to provide in this study.
3.3 Analysis The approach used in this study was thematic analysis, see Section 2.2 for a detailed explanation. The process of thematic analysis is defined by Braun and Clarke (2006) in six steps: 1. Familiarizing yourself with the data, 2. Generating initial codes, 3. Searching for themes, 4. Reviewing themes, 5. Defining and naming themes and 6. Producing the report.
1. Familiarizing yourself with the data The first step consists of transcribing data (in the case of video or audio tapes), reading and re-reading all the data to note down first impressions and initial ideas. If the data has been collected by the analyzer, then the analyzer has a certain knowledge of the data before
CHAPTER 3. APPROACH
13
this step. The purpose of the step is to immerse oneself with the data, reading actively and searching for meanings and patterns. It is ideal to go through the entire data set before the coding begins. This step forms the foundation for the entire process, and should therefore not be skipped or rushed.
2. Generating initial codes In step two the researcher is arranging interesting excerpts from the data systematically and grouping them into data sets called codes. A code identifies a feature found within the data content which could have a semantic (explicit) or latent (implicit/hidden) meaning. Coding will depend on whether the analyzer seeks to code the content of the data set in its entirety, or rather to identify a particular set of features within the data. The analyzer codes by tagging and naming selections of text within each data item. It is suggested to keep a little of the surrounding data if relevant, to preserve the context of the content.
3. Searching for themes Step three is based on sorting codes in groups that may form themes, then gathering data relevant to these potential themes. It is recommended to use visual representations to help deciding how codes together form a common theme. Therefore mind maps are a common tool.
4. Reviewing themes Step four of the process begins when a set of potential themes are defined. The purpose of this step is to refine the themes, merge themes that are closely related, or break up a theme into separate, more specific ones. Other candidate themes might be excluded from the final results due to lack of data or data consistency. All of the candidate themes are however presented in their own respect in a mind map for transparency. The step is divided into two levels of reviewing and refining the themes. Level one involves checking whether the themes are correctly placed with respect to the coded extracts, and deciding if a coherent pattern can be found. Level two involves checking the themes with respect to the entire data set, thus rendering a thematic "map" of the analysis. A Thematic map is a map of relations between the themes in the data set. Level two also involves reviewing whether or not this map
CHAPTER 3. APPROACH
14
accurately represents the patterns in the data set. If the map proves to match badly with the data set, the analyzer needs to repeat the analysis and refine until the map satisfies the requirements of accuracy.
5. Defining and naming themes In step five the analyzer refines the specifics of each theme and the overall story told by the analysis. The analyzer generates clear definitions and names for each theme. The step begins once the analyzer has produced a satisfactory "thematic map" of the data. A thematic map is satisfying if it has consistent relations between the themes, and the map fits the data. If the themes fit, data extracts within each theme appear to form a coherent pattern of what the data is telling us. Whether a thematic map "accurately" represents the data may depend of the theoretical and analytic approach.
6. Producing the report This step is the last opportunity to analyze. The analyzer selects relevant and compelling examples, relating the results of extracts to the research question and literature.
3.3.1 Details Inspired by Brooks et al. (2015), a subset of the data was analyzed before all the data was collected, and the rest was collected and analyzed based on the early findings. This means the analysis was done in two steps; once during an earlier stage of the data collection, and once when all the data was collected. Approximately two hundred hours of video material in addition to around a hundred pages containing diaries and retrospectives were collected. The amount of data combined with a limited time for analysis, resulted in a need to limit the span of the analysis. The reason for analyzing in two steps was to earlier gain insight in the nature of the data, thus narrowing the further collection of data towards the areas of importance. The desired results from doing this was to limit the data quantities, and more easily identify important themes in the limited time span during this study. The data was fed into a software tool for qualitative analysis, NVivo 11(NVivo (2017)), and coded according to the process described by Braun and Clarke (2006) in both iterations of the analysis. The coding was mainly theory-driven, with the goal to identify existing themes known within the
CHAPTER 3. APPROACH
15
similar method, Pair Programming. Videos were transcribed with the initial thematic map made from the rest of the data as a basis. Therefore the incidents captured were chosen based on a potential relation to one or more themes already defined in the initial thematic map, thus not transcribing all video material reviewed. Then the transcripts were collected based on the existing themes, this time setting the foundation to mapping the whole data set. The filming of the team was plagued by technical difficulties and therefore the entire process was not filmed. See Figure 3.1 below, which shows what entries of video material were transcribed. From about 180 hours of videos, 60 hours, or roughly 30% of the video material was reviewed. The sequences were intentionally evenly distributed over the work period, in addition to being selected based on interesting incidents reported in diaries or retrospectives, seeking to find more material confirming the reports. It was also possible to identify evolution or development by transcribing incidents spread over time.
Figure 3.1: The type of work done during the project, and what entries were reviewed or transcribed.
3.4 Summary of Approach Mob programming was practiced for 2.5 months, followed by 1 month of pair programming, and ended with 2 more weeks of mob programming, resulting in a total of 3 months of mob programming. Data was collected as diaries, retrospective meetings and video tapes. There were approximately 100 pages of text, and 180 hours of video material, of which all the text was analyzed, and roughly 30% of the video material was reviewed. Not all contents of the
CHAPTER 3. APPROACH
16
video sequences were transcribed, only the parts found interesting based on the earliest findings in step 1 of the analysis. Analysis was conducted in two iterations, using the six steps described by Braun and Clarke (2006) as a guideline: 1. Familiarizing yourself with the data, 2. Generating initial codes, 3. Searching for themes, 4. Reviewing themes, 5. Defining and naming themes and 6. Producing the report. The video tapes reviewed were evenly distributed across the work period, as shown in Figure 3.1.
Chapter 4 Results 4.1 Results first analysis iteration The first analysis iteration of a subset of the data (Diaries and retrospective meetings) yielded six themes as shown in Table 4.1 and Figure 4.1: Mood, Motivation, Team Dynamics, Pair Programming, Problem Solving and Learning. Some of the themes found, like Team Dynamics, Mood, Motivation and Problem Solving were already believed to have a strong support within the data, whereas problem solving initially was theory driven. The theme Learning had background in the existing theory (Section 2.1.2), and were therefore interesting topics to study further. Pair Programming emerged as its own theme because it was used during a fair amount of the project, and therefore made potential room for comparing the differences in being two or three developers on one computer. Table 4.1 below shows the initial main themes. Table 4.1: Initial main themes Theme Mood Motivation Team Dynamics Pair Programming Problem Solving Learning
Figure 4.1 below shows a thematic map with the themes and their corresponding subthemes. Notice that several items in the mind map are interconnected, and a few "child" items have more than one "parent". The reason for this the relations between the themes
17
CHAPTER 4. RESULTS
18
and sub-themes, and their complete properties were yet uncertain. The mind map shows both "known" and potential relations, resulting in the complexity and disorder.
Figure 4.1: Initial thematic map after analyzing a subset of the data
4.2 Final results In this section, excerpts of the video transcriptions, diaries and reports are presented along with explanations. Pair programming was removed as a theme because the amount of data was not considered strong enough for comparison, and the few entries were at best a couple of anecdotal opinions late in the process. Other themes were merged (collapsed into one theme) and adjusted to more fitting names during the refinement of the analysis. The second and final stage of analysis resulted in four themes; Learning, Personal Dynamics, Team Dynamics and Software Development, as seen in Table 4.2 and Figure 4.2.
CHAPTER 4. RESULTS
19
Table 4.2: Themes and sub-themes Theme Sub-theme Personal Dynamics Fatigue Motivation Learning
Knowledge Transfer Adaption to the Process
Team Dynamics
Role Switching Work Atmosphere Cooperation
Software Development
Problem Solving Code Quality Productivity
Figure 4.2: The final thematic map after analyzing all the data.
4.2.1 Learning Learning is a theory-driven theme that from the beginning of the process was classified as an interesting topic to investigate. Knowledge is believed to be passed between peers in several
CHAPTER 4. RESULTS
20
ways when practicing pair programming (Section 2.1.2), and is also claimed to be the case for mob programming.
Knowledge Transfer The team passed a lot of knowledge between one another during the development. Especially the use of tools and coding practices seemed to be passed between the developers early in the process. Below is a an extract from [Appendix C: Themes from analysis, p. 73] . At times however, as driver, I felt that the navigators maybe took a bit too much detailed control. This happened because I had a way I usually generated code, but they were used to another. After learning my teammates’ way however, that specific conflict might not happen again. I learned something new about the java editor, but the flow broke. Such interactions led to the team acquiring a common understanding and method of how to do things. At some occasions, one or more of the team members were encouraged to adjust their methods, which seemed difficult at times. Coding standards were also passed between the developers, as seen in the interaction below. Elias (showing a code line) : Is it better to have it like this? Or not. Ole: In that case make it consistent, because it’s not that way above. Christian: Just don’t do it instead. Ole: No, don’t do it, because that’s often known as a deconstructing way to write it. If you deconstruct an object you have spaces between the edges, while if you make it you don’t. [Appendix C: Themes from analysis, p. 78] The team members made each other aware of the best practices that they knew, and by sharing this knowledge occasionally, the result might be that everyone came out of it as improved developers. By struggling with unfamiliar technologies, the team members gained a detailed insight. "We learn much more about setup and new technologies" [Appendix C: Themes from analysis, p. 71] . Handling challenging new technology on their own might also have been harder and demotivating for the individuals, compared to when facing the challenges together. By working together and keeping up the work spirit, the team seemed able to stay on
CHAPTER 4. RESULTS
21
track for a longer time than the individuals in the team might have done. In the extract from a diary below, it appears that facing a problem together allows for motivation and learning. Other than that, I was motivated by the fact that the whole team googled and discussed the errors. When facing such errors on my own, a googling session could take a lot longer time. [Appendix C: Themes from analysis, p. 73]
Adaption to the Process Mob programming was a new concept for all participants in the beginning. This meant a lot of adjustments had to be done along the way. Arranging daily retrospectives, the team evaluated the quality of the process, and made the process evolutionary as suggested by Zuill and Meadows (2016). The retrospectives seemed to work well, and the weaknesses reported earlier in the process regarding navigation and cooperation were handled, as seen in the extract from a demo meeting below. How can we improve this? We suggest that sometimes we can be more independent of the timer, and use it like a guideline.Another suggestion is to try a day without driver, and try to find a fitting time to switch (ie: the one with the thought, shall not drive) [Appendix C: Themes from analysis, p. 50] By working closely together the team also seemed to get familiar with each other’s characteristics already a few days into the process. Navigation worked better than yesterday, we seem to be learning already the basics of each other’s quirks. [Appendix C: Themes from analysis, p. 48]
4.2.2 Team Dynamics The theme team dynamics remained through the second and refining iteration of analysis, but with slightly refined sub-themes: role switching and cooperation. These sub-themes are explained in this section.
CHAPTER 4. RESULTS
22
Role Switching Role switching is an essential part of mob programming to make sure that all participants stay focused. Wilson (2015) suggests that in a three man team, the roles should be switched every 10 minutes. Using such an experience report as a guideline, that is where the team started out. The timing soon changed however. Worked well with the process, it gets more and more natural, and I notice the new timing with 7 minutes followed by 3 minutes to finish up and change driver, works much better than 10 minutes on, 1 minutes change. [Appendix C: Themes from analysis, p. 50] Still the role switching evolved once more, and eventually the team discovered that the timer cause more annoyance that it contributed. Working without timers worked well. We switch more rarely, but there’s more natural points to switch, like a completed feature, or when someone needs to catch up. [Appendix C: Themes from analysis, p. 47] This kept developing, and already after the second sprint the clock ringing to alert switching seemed to cause more annoyance than it helped. Therefore the process ended without any timers to indicate role switches. However, it was pointed out in a sprint retrospective that there were other, more fitting points to change. It is likely that such arrangements will vary from team to team and depend on what value it provides the team. However in this case it seemed like a nice tool early in the process to guide the role switching, but as the team adapted to the work flow, the rigid timer broke natural variations for a fitting change of roles.
Work Atmosphere An important factor for a motivated and productive team is the work atmosphere and mood. According to Williams et al. (2000) developers enjoy themselves when pair programming, therefore the mood of the team members or work atmosphere, was interesting to observe. The fact that the team members are friends and have known each other for years should be taken into consideration. Still, it seems like being three developers led to enjoyment similar to what has been observed earlier about pair programmers. It seems like working with mob programming really strengthens a team’s atmosphere, and there were several observations that indicated enjoyment. The enjoyment might also have affected the motivation and
CHAPTER 4. RESULTS
23
productivity of the team in a positive manner. The interaction below is an example of how the team could celebrate after working out solutions together. An extract of conversation is given below.
Elias: A number can’t contain another number. The thing is that we must convert them to strings. We must make sure the numbers are strings. Couldn’t we say... how... Ole: I’ll look it up. Elias: I have a way meanwhile. A quick-fix. Elias (refers to what he’s typing on screen): You take that plus that Elias (laughs) Ole (glances at the screen): No Elias (smiling): This is a hack. Just to check that the.. Christian: I don’t think that will work Elias (keeps typing): Why won’t it work? It is a string now. Christian (laughing): This is fricking hacky Elias (typing and running the result): He-he-heyyyy Christian and Elias (laughing) Ole (shakes his head) Elias: The problem is that we’re searching with number equals number. If we don’t have any static types in javascript, we just have to hack around a string. Elias (keeps laughing) Christian: Well yes Elias: This worked Christian: It worked pretty well, too. Elias (laughing some more and takes a sip of coffee) Ole (keeps searching) Christian: It was fast too Elias: This was fast, Ole. Elias (jokingly): This is like it’s meant to be Ole (refers to the source in which he’s reading): The worst is that some people here say “take the number, and add an empty string”.
CHAPTER 4. RESULTS
24
(Everyone laughing) [Appendix C: Themes from analysis, p. 107] There were many incidents like the one above, where the developers made work into a game, and enjoyed humor that derived from common knowledge of programming. The daily retrospectives recommended by Zuill and Meadows (2016) were probably an important factor for the mood within the team. The main function of the retrospectives was to identify things that the team was doing well and keep doing these, it was also important for identifying things that were not going well and try to improve. The mood of the team was a bit mediocre at the beginning but now at the end of the day I myself and I believe the team as well feel we ended on a high point and are ready for tomorrow. [Appendix C: Themes from analysis, p. 103] The quote above from a diary refers to how the navigators tried to hold back some of the micromanagement that had been observed earlier, to avoid unnecessary conflicts with the driver.
Cooperation Mob programming is dependent on good working cooperation between team members. The roles of navigator and driver were roles the team members needed to adapt to. One thing that emerged early in the process, was that the team members were unused to the role of navigator, and therefore made mistakes like "micromanaging" the driver. At times however, as driver, I felt that the navigators maybe took a bit too much detailed control. This happened because I had a way I usually generated code, but they were used to another. After learning my teammates’ way however, that specific conflict might not happen again. I learned something new about the java editor, but the flow broke. [Appendix C: Themes from analysis, p. 65] From this diary extract, the fact emerged that different people have different means of reaching the same goal. The navigator knew of a more efficient way to complete a task, but due to the driver not knowing of this feature in the code editor, the interaction ended with a broken
CHAPTER 4. RESULTS
25
work flow. Had the driver instead been allowed to work the way he wanted, the navigators could have informed the driver, that another option exists. The team had clear thoughts on how to solve the issue with too detailed control of the driver, as seen in from a sprint retrospective below. More focus on letting the driver do things the way he wants and correct afterwards. Don’t scream out mistakes as soon as they appear, often the person writing knows they are there and will fix them anyway. How could we fix it: This can be achieved by first telling the driver the goal of the work session. Instead of guiding for every line. This means the driver knows what to do and can work fairly independently instead of being forced to write every line by listening to others. This gives more freedom and prevents annoyance. [Appendix C: Themes from analysis, p. 63] It is is recommended by Zuill (2014) to take such actions, for the team members in a mob to treat each other with kindness, consideration and respect. In this case of micromanagement, the navigators kept calling out typos, although these are inevitable during a session at the keyboard. This annoyed the driver.
4.2.3 Software Development In addition to how mob programming works for the people involved, the technical details play an important role. There are several aspects of the software development that were interesting to investigate.
Problem Solving A theory about collaborative work like pair programming, a theory also applicable to mob programming, is that complex tasks are solved more easily Williams et al. (2000). During this study there were several incidents indicating that this theory could be correct. We solved the problems together with different solutions, and mistakes were continuously corrected as we coded. When we got stuck, we fixed it swiftly for the most part. The last problem, we were unable to fix today, but we were able to identify where the problem is caused, and now only need to find out how to fix it. [Appendix C: Themes from analysis, p. 87]
CHAPTER 4. RESULTS
26
By collaborating and discussing, the team was able to identify problems as they emerged, and by discussion breaking down the problems to an understandable abstraction. In the conversation below, the team was in the middle of solving a problem.
(Ole is the driver. The team has trouble with search fields in a table) Elias: Huh? What happens if you search on date updated, then? Ole (types on keyboard, searches) Elias (chuckles) Christian: What’s up Elias: Nah, the search is weird Christian: Agreed Elias: Is there any, is there any lacking.. I think I know where the error might be. Ole: Okay? Elias: I think it could be lacking consistency between the number of searchable items, and the number of columns. Because we’ve copied this table from an entirely different place. So it could be that that’s why...because what it seems like now is that, maybe the reason why it’s undefined is because there isn’t any column that consists.. Christian: Right. But which “View” are you in now? Elias and Ole: Cases Christian: Okay, that makes sense. Because I believe the react table searches for reports, not cases. Elias (slightly doubtful): Yeah. . . (Few seconds pause) (At this point Christian stops paying attention any more) Elias (reads code out loud): Filter dot ID. Filter dot value. So that’s the way we searched in the report table. But it’s probably not similar here. Elias: Could you check what it’s like in the report table? I just want to understand how we’ve implemented it Ole (shows in code): Here’s an own filter method for this one. Elias: Yeah Ole: For date Elias: mhm
CHAPTER 4. RESULTS
27
Ole: We might have to have that here too Elias: So we must [Appendix C: Themes from analysis, p. 90] In the situation above the team struggled with an error in a search field. The whole team contributed with ideas as to how the problem could be solved. By discussing ideas and observations related to the problem, the entire team nurtures a creative problem solving environment, which leads to good solutions.
Code Quality According to theories about both pair programming Williams et al. (2000) and mob programming Zuill and Meadows (2016), the quality of the work done is increased. There are incidents from the extracts supporting such theories, where the team members were pleased with the design quality: We set a good standard for naming convention and formatting swiftly. There were several interactions in the video tapes where the discussion probably resulted in a better code base than if one of the developers had written code. Christian (typing as instructed) Ole: And then.. Naah not quite, you need Elias: Self-closing Ole: Yes, so a slash, and then close. Elias: And it’s normal to have a space after. . . before the slash. Ole: Yes, that’s normal convention Christian (finishes typing): Like that Ole: Yes, so that’s a self-closing tag. [Appendix C: Themes from analysis, p. 59] In the interaction above Christian as the driver is unaware of the standards that the two peers are familiar with. By all contributing to the solution together, code standards get known to the whole team.
Productivity Productivity was a difficult factor to measure in a qualitative study, but there were many incidents of the developers feeling productive, and experiencing that the work flow was efficient.
CHAPTER 4. RESULTS
28
Today was a very productive day. We implemented all rest api endpoints for user and added lots of tests. It all went really smooth and collaboration worked really good. No major set backs and lots of progress. All in all very happy with how smooth the system worked today. [Appendix C: Themes from analysis, p. 96] There were however incidents where one or more of the team member felt useless and unproductive while facing difficult challenges, but that may have depended more on the type of work, and might well have been just as challenging when developing alone. The choice of approach when solving a problem, and the knowledge to find an easy solution provided progress, as seen in one of the daily retrospective meetings from below. We got a lot of stuff done, was productive. Based on our choice to use of the library react-table, lots of functionality was easy to implement. [Appendix C: Themes from analysis, p. 95] Still productivity would depend on the type of work, as many tasks with simple implementations did not require the whole team.
4.2.4 Personal Dynamics The personal dynamics theme combined the sub-themes motivation and fatigue, both being theory-driven topics. An interesting point about a method like mob programming is the stress it puts on the involved individual, which similarly to pair programming requires an intense focus from the participants.
Fatigue There were several instances, especially early in the process, where the developers in the team got exhausted: Our work didn’t start before around 12:30 due to working on another project (CCD) and therefore we decided to work until 18:00. I am very exhausted after today’s work, maybe because it is monday, maybe because we worked late just setting things up which i am not a fan of. I feel the team worked well today and we got work done, although my mood was declining towards the end and did not match
CHAPTER 4. RESULTS
29
my fellow teammates. [Appendix C: Themes from analysis, p. 68] In this snippet from his Diary, Christian experience fatigue from a day lasting less than 6 hours. There could be various reasons for this, as he discussed himself, but it was a typical tendency in the early weeks of the project that the team got worn out during the days. The team tackled issues quite intensively, and maybe because of peer pressure, the opportunity to take more regular "micro-breaks" was not present. Instead the team had to take breaks as a unity, something that might not have been well enough planned early in the process. Below is a conversation where an example related to the theme fatigue was found. (Driver switch Christian to Elias. The team has spent more than an hour struggling with a test that won’t run due to issues with rendering. ) Elias (while switching seats): Darn, I feel tired Christian: So do we all Elias: What if we work a little bit more with this, and if we’re stuck, then we make the wiki, and then come back to it. Ole: mhm Christian: Until half past. It’s not much but... Elias: Let’s try 8 minutes more to wrestle with this, and if it won’t work we’ll take a break from this and work with something else. Ole (proceeds with the problem at hand): Let’s test something. [Appendix C: Themes from analysis, p. 70] In the extract above, the team agrees that they get nowhere if they keep struggling on the same issue for much longer. Due to the daily retrospectives however, the team attempted at solving the issue of fatigue. Days were planned in detail, with explicit times set aside for breaks, as shown in Figure 4.3 below.
CHAPTER 4. RESULTS
30
Figure 4.3: Plan for a work day with time set aside for breaks
The actions the team made to adapt their process eventually seemed to work. It was reported in the latest Sprint Retrospective, two and a half months into the process, that the team members no longer got tired like earlier. This was something that had been noticed the last few weeks before the meeting was held. The action taken to control breaks might have had an effect on this, but also the adaption to the process, as the team over time got used to working like drivers and navigators.
Motivation Another sub-theme related to the theme personal dynamics found was the factor of motivation. Due to individual preferences, the developers experienced different degrees of motivation at different stages of the project. Early, while working on unfamiliar technologies and setting up the work environment, the team faced many challenges they struggled to tackle. This also affected the morale. It was demotivating to only work with setup again. I had long periods of time
CHAPTER 4. RESULTS
31
where I really felt I could have been of better use doing other stuff. Other times, the cooperation was productive in finding problems. [Appendix C: Themes from analysis, p. 83] There were several other diaries where the work with setup, and little production of actual features drained the motivation of the team. The team needed external help at times, and to fix difficult issues with the help of a senior developer in a small session was rewarding and gave every developer the motivation to move on and tackle the next problem. Still, the difficult parts of the project seemed to leave their marks, and long days of struggle with the specific kind of work left a sore association with it, as seen in the conversation below. (Christian is writing report, Ole and Elias are pair programming) Ole (regarding Docker, talking to Christian): You miss this don’t you? Elias: Run it Ole: Do you miss this? (once again talking to Christian) Christian: Hmm? (Looks at screen) Christian: No (smiling) [Appendix C: Themes from analysis, p. 85] Going back to harder work instantly had a negative effect on the morale of some of the developers, because of the earlier struggles with the previously foreign technology. It appears however that in general, the enjoyment coming from good working atmosphere and the ability to motivate each other, led to a strengthened motivation for each individual.
Chapter 5 Discussion 5.1 First analysis iteration The first analysis iteration of a subset of the data (Diaries and retrospective meetings) yielded six themes as shown in Figure 4.1: Mood, Motivation, Team Dynamics, Pair Programming, Problem Solving and Learning. At this stage there were many interesting entries of data that were discovered. The reason why pair programming emerged as a theme was that it was reported to feel more productive than mob at some points. Even when the developers were sitting at the same table working on unrelated tasks. A temporary mob could quickly be assembles should the need arise. Pair programming is its own method and therefore does not fit into a thematic map for mob programming. The pair programming theme did not align well with the rest of the themes and the study was instead focused on mob programming.
5.2 General Discussion There are many interesting aspects that have emerged from researching mob programming. Both how the method influences the software development itself, but also how it affects the developers participating. The themes discussed in Section 4 revealed both potential benefits and risks with the development method. Potential benefits were good productivity in certain types of work, improved problem solving and satisfying code quality. Even though productivity might be regarded as low when doing simple tasks, the navigators could then utilize their role to think strategically to find the next step while the driver implements the solution. It is however hard to conclude on this without conducting experiments with productivity in
32
CHAPTER 5. DISCUSSION
33
focus. The benefits of problem solving and code quality match the known benefits found in other studies presented in Chapter 2.1. The observations of enjoyment and positive motivation were also present. In this study the results also pointed to mob programming being a viable arena for learning and knowledge transfer. Such observations may provide a strong argument to make use of mob programming in an educational context. Retrospectives were held with the purpose of improving the process, and appear to be useful for learning and keeping up team morale. How the method would have affected senior developers is from this study unclear, as this study had observations of three junior/novice developers. It has however been observed by Cockburn and Williams (2001) that also senior developers seem to benefit from pair programming with a junior developer, thus a team of experts in a mob might provide learning for already knowledgeable developers. As software development is a constantly evolving field, the demand to acquire new knowledge is high. Several of the risks made known in Section 2.1 appeared to be true early in the process. The team had in the early stages issues with finding a good work flow, this led to experimentation with the timer. There was also a struggle with the navigators being too focused on details, and by that interrupting the flow. The developers experienced exhaustion early in the process, although this seemed to improve as reported in the later retrospectives. These issues were identified as they arose, and the team took action to solve them through decisions made during daily retrospectives. The daily retrospective meeting proved to be a valuable asset when practicing this development method. It did, as described by Zuill and Meadows (2016), work well to adapt the process to this particular team. The navigators got more self aware and made sure that the driver was allowed to operate freely. This was in accordance with what is explained by Zuill and Meadows (2016), that the navigators should fit their explanations to the situation, and navigate at the correct level of abstraction (Section 2.1). Why fatigue ceased to be an issue could be due to various reasons. It is possible that it is related to the team finding a good break model where they cut out the timer and took breaks when the need arose. Another reason might be that the developers got used to the work flow, and were past the most demanding problem solving period where the same problem could stick for days. In the end the team managed to tune and adapt the process into something that worked well, produced results, and did not strain the developers too much.
CHAPTER 5. DISCUSSION
34
5.3 Limitations There are several limitations to the scientific approach used in this report. The access to a proper control group would have been ideal. However, in this report the only team of developers was ourselves. This means the team’s experiences of the method had to be observed in retrospective, which could raise questions about the validity of the results. In a conversation with an expert on Software Processes, Professor Torgeir Dingsøyr (see (Dingsøyr, T. (2018)), it was made clear that studying yourself is both difficult and unconventional. Keeping that fact in mind, the goal was to tread carefully throughout the whole process, and gather data in an objective manner. The results in this study can not be generalized for all developer teams, so the external validity of the study is not considered strong. This is both due to the study being of a qualitative nature, but also that it is conducted on students. The internal validity might be threatened by the fact that any reactions or behaviour observed, could have been affected by a third variable, thus not a result emerging from the fact that the team was mob programming. The general mood of the team members might affect how they regard the mob programming, and therefore it might not give a clear and objective view of the method. Also the fact that we have been studying ourselves might have affected behaviour in some way.
The team The team for this research consists of three developers who have known each other for a long time and have learned programming together. The teammates would therefore have much of the same knowledge in programming, which could skew the results and experiences of the process, as a team of experts is considered a better setup Zuill and Meadows (2016).
Organizational Culture When mob programming it is said that the people with the ability to make important decisions for a project should be present. In this case, although presented with a good amount of creative freedom, we were still following goals set by people who were not present during mob sessions due to having work themselves. Ideally the people with ability to make decisions, for example the product owner should be present during a session every now and then so that important decisions can be made. This may have weakened the results, since
CHAPTER 5. DISCUSSION
35
this doesn’t strictly follow the best practises of mob programming.
5.3.1 Data collection Several times during the process, especially after struggling with difficult tasks writing the program, the teams motivation to write detailed diaries was weakened. This might also have affected the quality of some of the daily retrospectives. The absence of any external interviewer could possibly make data collected from ourselves subjective. It could also possibly be regarded badly written and unstructured, due to inexperience in this type of data collection. Such possible weaknesses might limit the results when analyzing it at a later point. However, the lack of knowledge on the field of Thematic Analysis in the period of data collection might be an advantage. The production of our own transcripts would not be influenced by any pre-acquired knowledge about the form of analysis, as we had none during that time period. Additionally, even though some parts of the video tapes might render worthless because of awareness, it was not likely for the team to constantly remain aware of the camera watching at all times. Therefore there could be a lot of interesting video material where we as subjects could observe our own behaviour retrospectively, in that way reducing the risk of anecdotal or biased conclusion.
5.3.2 Analysis There was limited time available to transcribe the video material collected. Therefore the more available data (the diaries and retrospectives) was analyzed first to define a set of themes. While transcribing as much video material as possible in the limited time span, there were attempts to identify relations to topics defined in the first part of the analysis. The collection of data from the videos was very selective, and nowhere near the whole set of videos was transcribed, which leaves lots of undiscovered features that might lay within the data. The videos were transcribed and translated directly from Norwegian to English, to save time translating all of it later. This is usually disregarded and may threaten transparency (Nikander (2008)). However because of the close relation to the data (the researchers studying themselves) little of the meaning is likely to get lost in translation. Lacking experience of thematic analysis, in addition to a very short time span might also limit the quality and depth of the analysis. The transcription work in itself might be limited by lacking knowledge of what to look for while working through the material, and lacking knowledge of state-of the
CHAPTER 5. DISCUSSION
36
art transcription.
5.4 Other Observations 5.4.1 Focus There were multiple occurrences of developers not paying attention to their work during the video footage. This resulted in a hypothesis that during mob programming, there is a lower threshold to drift off into unrelated activities than in pair programming due to being part of a crowd. It could be argued that since the team knew each other so well during this process, they had no need to "impress" each other. This means once again that the threshold to drift off is reduced. It is very quickly noticed in pair programming if your partner is not doing what he is supposed to, as described by Williams et al. (2000), therefore pair programming might have an efficiency advantage. Also when participating in a team with members who do not know each other that well, this comes with an implicit need to fit in. Doing unrelated activities during work would be looked down upon and therefore the threshold for doing so is a lot higher. The question whether drifting off is inherently a bad thing was asked. Even by Zuill and Meadows (2016), it is said that the developers are always able to take a break when necessary, so arguably this may actually be a good thing. By having such an arrangement, it may be possible to avoid fatigue in a larger mob of 4-5 people, as the progress will continue when one of the developers needs a break. This was however harder to manage for a team of only three developers, as the mob was easily vulnerable to shortage of people. There were not enough data to make any conclusions regarding this comparison between mob- and pair programming. It would be interesting in future studies to keep these phenomenons in mind and look into them.
5.4.2 Code Produced To give a perspective of the work done for the interested parties, this section gives some numbers related to code production during the project period of Feb 02 - May 02, from when the coding started until feature freeze, which means no more new functionality was produced. The numbers in Table 5.1 were accessed from the Statistic tool (JetBrains (2018b)) in the integrated development environment(IDE) IntelliJ IDEA (JetBrains (2018a)).
CHAPTER 5. DISCUSSION
37
Table 5.1: Code Produced File type Code lines cmd 143 html 81 java 2985 javascript 2926 scss 740 shell 38 sql 268 yml 102 Total 7283
The content above adds up to 2427 code lines per developer, over what has been calculated to 45 days of development. This gives a daily production of 54 functioning code lines, or 270 lines a work week. In Table 5.1, code related to XML, package managers and so on are disregarded. Productivity is not necessarily measured in number of code lines, but solving problems. It could also be argued that an excellent developer writes the same solution in fewer lines, and more maintainable code.
5.4.3 Work environment The set-up is important when trying mob programming. It was found that having a whiteboard (or any easy accessible visual aid), can be a huge advantage for planning and discussion. The ability for the team to gather around the whiteboard to draw and list ideas was very helpful when discussing technical or strategical tasks. The timer was found to be a useful tool for guiding the early process, and adjust the participating developers to the frequent change of focus and tasks. Once the developers are comfortable with switching, it becomes more of a annoyance to follow rigidly timed schedules. Therefore it is recommended to test what works and to consider not having a timer after a while.
Chapter 6 Conclusion and Further Work 6.1 Summary and Conclusions Based on the results of this study, mob programming is a viable development method with strengths and limitations. The main objectives in this report (Section 1.2.3) were to identify potential benefits and risks of the method, and match observations with other already identified features. The following potential benefits and risks were found.
6.1.1 Benefits Productivity Is experienced at certain tasks, especially complex tasks that are difficult for a single person Problem Solving Seems to be of a higher level Code Quality The code base is consistent and concise, with low amounts of defects Enjoyment Comes from good work atmosphere and fun Motivation The teammates might motivate each other
6.1.2 Risks This team found that many of these risks can be avoided by adapting the process along the way. Bad cooperation The navigators may sometimes focus too much on details by micromanaging, thus bothering the driver, effectively slowing progress 38
CHAPTER 6. CONCLUSION
39
Fatigue Mob programming is tiring because of the intensity that comes from peer pressure Bad Timing of Role Switching The work flow might be disrupted
6.1.3 Conclusion Mob programming appears to work well for developing good solutions to critical and complex parts of a system, yet slow at parts that are repetitive and easy. Some of the same benefits and issues from pair programming presented themselves when mob programming in a small team. One of the main potentials of mob programming appears to be the transfer of knowledge between team members. Programming with others seems to nurture good programming habits including formatting, design patterns, tool usage and other small details related to programming languages. Such knowledge may not be acquired from a supervisor or teacher, but is rather likely to be passed from student to student. The quality of the product also seems to be fairly good, with defects being corrected continuously. It strengthens the team, but can also be draining on energy and mood because of the intense focus required. Mob programming is enjoyable by all involved developers, even though working closely together could bring up the risk of small annoyances.
6.2 Further Work 6.2.1 Further research It would be interesting to perform research on a large control group (i.e. a class in an course about Software Engineering, thus performing a quantitative study to generalize the results found in this study. The focus in such a study could have been to objectively compare the productivity of mob programming, and a more traditional method where the developers work individually. This could have been realized by having half the control group (ex. 30 teams) develop in a project using mob programming, while the additional 30 teams could have used a more traditional development process to solve the same tasks. Another interesting research would have been to conduct an empirical study with professional software developers using practicing mob programming. Such a study may give answers with a higher external validity, as the implications towards the industry would be more believable with the research being conducted on people from the industry (Jørgensen (2017)).
Bibliography Aref, M., AlAzzam, I., and Alsmadi, I. (2013). The impact of using pair programming: a case study. International Journal of Teaching and Case Studies. Balijepally, V., Chaudhry, S., and Nerur, S. P. (2017). Mob programming - a promising innovation in the agile toolkit. In AMCIS. Boekhout, K. (2016). Mob programming: Find fun faster. In Sharp, H. and Hall, T., editors, Agile Processes in Software Engineering and Extreme Programming, volume 251, pages 185– 192. Springer, Cham. Boyatzis, R. E. (1998). Transforming Qualitative Information: Thematic Analysis and Code Development. SAGE Publications. Braun, V. and Clarke, V. (2006). Using thematic analysis in psychology. Edward Arnold (Publishers) Ltd. Brooks, J., McCluskey, S., Turley, E., and King, N. (2015). The utility of template analysis in qualitative psychology research. In Qualitative Research in Psychology, pages 202–222. Taylor & Francis. Caspers, M. K. (2017). React and redux. In Rich Internet Applications w/HTML and Javascript. Oldenburg. Chong, J. and Hurlbutt, T. (2007). The social dynamics of pair programming. In Proceedings of the 29th International Conference on Software Engineering, pages 354–363. IEEE Computer Society. Cockburn, A. and Williams, L. (2001). The costs and benefits of pair programming. In Succi, G. and Marchesi, M., editors, Extreme Programming Examined, pages 223–243. AddisonWesley Longman Publishing Co., Inc. 40
BIBLIOGRAPHY
41
Dingsøyr, T. (2018). Personal interview. Interview type: Skype call. Docker (2018). Docker. https://www.docker.com/. Gill, P., Stewart, K., Treasure, E., and Chadwick, B. (2008). Methods of data collection in qualitative research: interviews and focus groups. British Dental Journal. JetBrains (2018a). Intellij idea. https://www.jetbrains.com/idea/?fromMenu. JetBrains (2018b). Statistic. https://plugins.jetbrains.com/plugin/4509-statistic. Jørgensen, M. (2017). Working with industry: Stories of successful and failed researchindustry collaborations on empirical software engineering. In 2017 IEEE/ACM 5th International Workshop on Conducting Empirical Studies in Industry (CESI), pages 46–52. Laumann, K. (2018). Personal interview. Interview type: Skype call. Nikander, P. (2008). Working with transcripts and translated data. Qualitative Research in Psychology, 5(3):225–231. Norwegian Public Roads Administration (2018).
Vegvesen homepage.
https://www.
vegvesen.no/en/home. NVivo (2017).
Nvivo.
http://www.qsrinternational.com/nvivo/nvivo-products/
nvivo-11-for-windows. Rising, L. and Janoff, N. S. (2000). The scrum software development process for small teams. IEEE Software, 17(4):26–32. Williams, L., Kessler, R. R., Cunningham, W., and Jeffries, R. (2000). Strengthening the case for pair programming. In IEEE Software, volume 17, pages 19–25. IEEE. Wilson, A. (2015). Mob programming - what works, what doesn’t. In Lassenius, C., Dingsøyr, T., and Paasivaara, M., editors, Agile Processes in Software Engineering and Extreme Programming, pages 319–325. Springer International Publishing. Zuill, zuill.
W. (2014).
Mob programming – a whole team approach by woody
https://www.agilealliance.org/resources/experience-reports/
mob-programming-agile2014/.
BIBLIOGRAPHY
42
Zuill, W. and Meadows, K. (2016). Mob Programming: A whole team approach. Lean Publishing.
Appendix A Acronyms NVDB National Road Data Bank (Nasjonal Vegdatabank) API Application Programming Interface UI User Interface NTNU Norwegian University of Science and Technology IT Information Technology REST Representational state transfer IDE Integrated Development Environment XML Extensible Markup Language
43
Appendix B Terms Sprint A small working period which ends with a demonstration of the work completed in the period. Used in incremental and agile development processes Empirical Based on, concerned with, or verifiable by observation or experience rather than theory or pure logic. Coding (Qualitative Analysis) The act of finding and grouping data by relations and patterns. Qualitative data Diary accounts, participant observations, in-depth interviews or documents. Theme Captures something important about the qualitative data in relation to a research question Sub-theme A secondary theme that derives from a larger theme, or with other sub-themes combines into larger themes. Example: theme (person), sub-themes (man and woman). Thematic Map A mind map showing the themes and sub-themes that have been found while coding. Mobbing A term for Mob Programming Level of Abstraction To what detail something is discussed or explained Package manager Manages installation, execution and removal of software packages.
44
Appendix C Themes from analysis
45
APPENDIX C. THEMES FROM ANALYSIS
46 15/05/2018 18:18
Coding Summary By Node Thematic Analysis Mob Programming 15/05/2018 18:18 Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
17/04/2018 14:57
EBS
13/05/2018 13:52
Node Nodes\\Adaption to the Process Document Internals\\2018-02-20_ Sprint retrospective No
0.3006
3
The workflow felt unnatural in the beginning, but has improved over a short period of time We got better to adapt navigation, as well as understanding each other better as driver. 2
2. Didn’t always follow the clock 3. We could switch more often when someone has an idea. The driver should not navigate himself. Generally switching driver 3
EBS
13/05/2018 13:52
2. Try to follow the clock as much as possible. Remind each others. Try changing times, especially the switch time, so we are able to wrap up a task 3. Everyone focuses on the task, and everyone should remind each other..
Internals\\2018-03-06_Sprint retrospective No
0.2087
3 1
EBS
13/05/2018 13:52
We have a flow with the timer that works well for uss. We use it more as a guideline, but fairly actively when we are actually writing code, and less actively when researching and testing. 2 Instead of following the timer stricly we can try being more free How could we fix it: Use timer as a guideline but switch mostly when we feel 3
EBS
13/05/2018 13:52
like it. EBS
13/05/2018 13:52
Use timer as a guideline but switch mostly when we feel like it.
Reports\\Coding Summary By Node Report
Page 1 of 62
APPENDIX C. THEMES FROM ANALYSIS
47 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
13/05/2018 13:52
Internals\\2018-03-20_Sprint retrospective No
0.2587
2
Working without a timer worked well, though sometimes maybe we are sitting too long. But it’s better to tell when you want to switch instead of being disturbed 2
EBS
17/04/2018 15:12
1
EBS
13/05/2018 12:03
Overall we have developed a decent process which works for us.
Internals\\2018-04-18_Sprint retrospective No
0.4908
5
We notice that we’re used to the workflow. We don’t get exhausted like earlier, something also noticed a bit before this sprint. 2
EBS
13/05/2018 13:52
Working without timers worked well. We switch more rarely, but there’s more natural points to switch, like a completed feature, or when someone needs to catch up. 3
EBS
13/05/2018 13:52
We felt that the roles in pair programming weren’t as distinguishable as in mob. When in pair, there was more a back and forth discussion of the development, while in mob, the driver has more than enough with catching all the commands from the navigators 4
EBS
13/05/2018 13:52
Sometimes we don’t switch often enough, likely because we don’t have a timer. But with a timer we experienced that the timer was an annoyance and broke the flow 5
EBS
11/05/2018 21:12
We took the right choices, but we should have come there sooner. We should find an easier solution instead of being persistent and fight the problem. We don’t ask for help enough when we’re struggling to avoid waste of time.
Internals\\Christian Echtermeyer Diary No
0.0384
2 1
EBS
13/05/2018 13:52
The process was smooth today and we switched often when programming. I also think the amount and frequency of breaks was good, i think we had around 5 total. My mood was good today and maybe even improved slightly by seeing uss get a lot of work done 2
EBS
13/05/2018 13:52
I felt the team worked well, we more or less ignored the timer but everyone got to write anyway.
Reports\\Coding Summary By Node Report
Page 2 of 62
APPENDIX C. THEMES FROM ANALYSIS
48 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
0.1452
21
Reference Number
Coded By Initials
Modified On
1
EBS
13/05/2018 13:52
2
EBS
13/05/2018 13:52
3
EBS
13/05/2018 13:52
EBS
13/05/2018 16:46
Internals\\Daily retrospectives No
We forgot to start timer
Try auto-timer.
Autotimer worked well, people forgot to put it on but now it seems to work well for us 4
Navigation worked better than yesterday, we seem to be learning already the basics of each others quirks 5
EBS
13/05/2018 13:52
6
EBS
13/05/2018 13:52
7
EBS
13/05/2018 13:52
Driver switching went well when programming
Driver switching can still be improved slightly
We want to try a different time, see how that works. Possibly shorter times, maybe more small break time aswell 8
EBS
13/05/2018 13:52
9
EBS
13/05/2018 13:52
10
EBS
13/05/2018 13:52
11
EBS
17/04/2018 14:22
12
EBS
13/05/2018 13:52
EBS
13/05/2018 13:52
Timing went well, 7+3 was better than 10+1
Keep doing 7+3 timing
What needs improvement? Used timer less Research time How can we improve this? Timer: try to keep to the process Implement research time in plan for the day
One notices the process is more natural
It’s nice to switch often, but still sometimes it feels like the time goes too fast. We lose the flow 13
How can we improve this? We suggest that sometimes we can be more independent of the timer, and use it like a guideline. Another suggestion is to try a day without driver, and try to find a fitting time to switch (ie: the one with the thought, shall not drive) Reports\\Coding Summary By Node Report
Page 3 of 62
APPENDIX C. THEMES FROM ANALYSIS
49 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
14
EBS
11/05/2018 21:15
15
EBS
13/05/2018 13:52
16
EBS
13/05/2018 13:52
What needs improvement? Comment code Can be improved by: Write documentation on every method when making them Avoid micro managing! typos as navigator Navigator explain where to fix stuff How can we improve this? Write documentation on every method when making them Stop micro managing! Describe where to fix stuff using line numbers
Sometimes the timer is useful, but other times it’s hindering progress.
Try to be more flexible with changes. Timer is to keep us reminded, but we should change more when we feel for it. 17
EBS
13/05/2018 13:52
18
EBS
13/05/2018 13:52
19
EBS
13/05/2018 13:52
20
EBS
13/05/2018 13:52
We worked without timer today, which felt nice and chill in a way What needs improvement? We were driving for too long How can we improve this? Reinstate the timer regime Use timer with max limit
We could have switched driver more often.
We did not switch roles often enough
Try to switch every time a feature has been implemented including related methods and sub-features 21
EBS
13/05/2018 13:52
1
EBS
23/04/2018 12:46
What needs improvement? Driver switching How can we improve this? Switch more often
Internals\\Elias Sørensen Diary No
0.2250
9
I had mixed experiences of the first day of mob programming. I felt at times that we had progress considering that we right there and then made a decent naming convention, and formatting was immediately set to our preference because we debated how it was supposed to be. At times however, as driver, I felt that the navigators maybe took a bit too much detailed control. 2
EBS
12/05/2018 09:34
To summarize: I partly liked the mob programming, but feel that to lack of experience with the working method, we had some lagging in the process.
Reports\\Coding Summary By Node Report
Page 4 of 62
APPENDIX C. THEMES FROM ANALYSIS
50 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
3
EBS
23/04/2018 12:50
Today was a good day of mob programming. As something I mostly experience when developing, we had some encounters with code failures we didn’t quite understand. However, we were able to stay bright, and took breaks when we had struggled for a long time. Work went well today, and we had fun programming together. The spirit was high during the whole session. We were more self aware, and took into consideration what we had from yesterday’s retrospective 4
EBS
13/05/2018 13:52
5
EBS
13/05/2018 13:52
2018-02-23
I felt like I got alot of stuff done today. As we switched drivers, code was written swiftly, and new components added with relative ease. I think we have found a decent timing with 7+3, and it feels like I’m productive. 6
EBS
23/04/2018 13:05
We made productive, working code, and I noticed that mostly, syntax errors were discovered instantly. Also, we had good naming conventions, and solved most problems that occured, rather swiftly. I got really frustrated with the error we had, but finally solving it was satisfying. 7
EBS
23/04/2018 13:06
I felt like today was an awesome day. Progress is easily noticed on front-end. Driving and navigating also feels better than earlier. We have started stating line numbers when the driver is trying to find where in the code the navigator is looking. That makes it a lot easier to find said code block when I’m the driver 8
EBS
23/04/2018 13:07
I also feel we are getting better at navigating at the correct abstraction, in other words not pointing out mistakes at once, but making the driver aware of them if needed after he’s done typing. We also let the driver take more control when he knows what to write to a greater extent. 9
EBS
13/05/2018 13:52
I felt today, with mob programming again, was nice. We had decent progress, and didn’t face any major problems. We didn’t use a timer at all today, which felt more relaxing. I felt I, and my teammates were useful
Internals\\Ole Kristian Aune Diary No
0.1137
3 1
EBS
23/04/2018 14:33
We had a really good session after lunch, and I feel we are good on track for this sprint although last sprint ended under the goal (it was way too ambitious). Looking forward to some frontend work the coming days. It’s the part I like the most, and find most rewarding. Hope I feel the same way when mob programming on this task also. 2
EBS
13/05/2018 13:52
Worked well with the process, it gets more and more natural, and I notice the new timing with 7 minutes followed by 3 minutes to finish up and change driver, works much better than 10 minutes on, 1 minutes change. 3
EBS
12/05/2018 09:19
At times there was some frustration and negative vibes, but we pulled through and got a lot done. We still need to get better at communication / explaining what we mean, and be patient when explaining to others
Reports\\Coding Summary By Node Report
Page 5 of 62
APPENDIX C. THEMES FROM ANALYSIS
51 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
0.1855
15
Reference Number
Coded By Initials
Modified On
1
EBS
14/05/2018 13:45
Internals\\Video transcriptions No
What was noticed from the initial video tapes was that the whiteboard was located to the team’s right side, which was part of the early setup. Also, during this early session of mobbing, there was a keyboard which the developers passed around. while sitting in the same chairs. At video 2, 6:50 during the second video of the day, there was a remark from Ole. Ole: Really a bit of the problem now, like we’re sitting right now, is that I can’t look things up. At this point Ole was sitting in front of his computer, unable to make searches as Christian occupied the chair with his own device. This resulted in a switch, Ole and Christian switched chairs, thus fixing the problem remarked by Ole. 2
EBS
13/05/2018 13:52
EBS
13/05/2018 13:52
At video 2 0,7:02 there was another remark from Ole as the developers switched chairs: Ole: We haven’t set up a timer yes, but that’s all right Elias: Yes, we could fix a timer then Ole: We can fix that Christian: So we can Ole Should we do that first? Elias Yes, do that. Download. 3 At video 0122, 14:15 The timer is discussed Transcript: Elias: "Work interval, 10 minutes" Christian: "Break could be." Elias: "25. Long break after... " Ole: "But do we want 25 minutes?" Elias: "How many intervals during a day? Since it’s ten minutes, it will be... Christian: We won’t bother to calculate that Ole: No, we can change it Elias: That would make it.. Ole(reading from the timer program settings): Work completed sound, alarm clock, end break sound. (mumbling) Elias: That would be 50 intervals then Christian: Sure. Ole: It doesn’t matter. Complete notifications (mumbling). Elias: Should we have autostart timer? Ole: No 4
EBS
14/05/2018 13:45
5
EBS
13/05/2018 13:52
Video 0123 2018-02-02 At video 0123, 10:35 Sunlight hitting the screen Elias: Now I notice a challenge with sunlight Ole: On my screen? Elias: The TV and my screen No action taken
Video 010122 At video 010122, 06:25 Comment about driving time Ole: Then I’ve got three minutes and 45 seconds left Christian: That’s kinda short Ole:, Yes, but it’s supposed to be like that Elias: Everyone’s supposed to feel like they’re writing all the time Stopped at 7:28 video 010122
Reports\\Coding Summary By Node Report
Page 6 of 62
APPENDIX C. THEMES FROM ANALYSIS
52 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
6
EBS
10/05/2018 11:10
2018-02-02 At 08:22: Fixed a typo done by the driver Christian, who remarked that the error should have been caught by the navigators. Ole: Should we write it every time there’s an “Echter-bug”? Elias: *Laughs* Christian: No, the “Echter-bug” is a part of you, because you guys didn’t catch it. Elias: We should’ve caught it Ole: That’s true actually Elias: Now we cannot blame, now we can’t point fingers and stuff 7
EBS
13/05/2018 13:52
Ole: Yes well... ...I know where we start Christian: Then you shouldn’t be the driver Ole: No, but I guess I just have to explain a bit to you Christian: ...No...you shouldn’t drive. Elias, do you want to drive? Elias: I could very well drive Ole: Okay, you won’t get to write so much right away, because there’s some stuff I must go through. (Elias and Ole switch seats) Elias: Is the keyboard connected? 8
EBS
10/05/2018 11:28
Video 010124 2018-02-05 At 06:23 Christian mentions problems with sun shining onto screen, the group agrees that there is a problem with the current setup, and decides to fix it by moving the whiteboard in front of the window. 9
EBS
13/05/2018 13:52
Video70124 2018-02-05 10:40 ( The timer beeps for switch while the team discusses folder and package structure, and Elias and Ole switch places. The switch seems to break the work flow. Elias becomes the new driver) Ole: Who is it? Christian: But we need the package first, it’s you Elias Elias: It’s me? Okay. Elias: Then we continue where we left off. Now it’s no longer me who decides what happens Christian: You can still participate in the decision making Elias: Yeah, I’ll come with input and discussion, but uh. Christian: We must have a “data” folder? Elias: But that doesn’t need to lay under “rest”. Christian: It’s not under “rest” now, it’s made under Elias: Data? Ole: What is data? Elias: Data-classes. It’s models. You could say it’s the data representation in the language of.. Christian: You could make a mock folder instead of data, because we technically don’t make data classes now. Or do we make data classes, only that we have a mock object in the data classes? *Keep discussing name conventions from REST documentation* 10
EBS
10/05/2018 11:50
Video50129 2018-02-15 03:10: (The team laughs because Christian types something weird on the Windows keyboard that has been wrongly mapped from the Mac. ) Mention from Ole (referring to the Mac keyboard): It might have been faster for you to learn that keyboard.
Reports\\Coding Summary By Node Report
Page 7 of 62
APPENDIX C. THEMES FROM ANALYSIS
53 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
11
EBS
10/05/2018 11:55
Video 30135 2018-02-21 19:28 Ole: I’m trying to find back how that Volume-stuff works Elias: What are you doing with volume now? Ole: Because if I just run Docker-Compose up build on the client with volume, we can just sit and code while it runs in docker, but it auto updates. That’s why I want that. Because it’s super super chill Elias: But if you know how to do it we can switch driver. Ole: But I don’t know how to do it Elias: But you’re figuring it out Ole: Yes Elias: What are we searching for then? Ole(stays as the driver): Either link local volume to something or, link volumes docker compose. Something like that. Elias(starts looking up solution) 12
EBS
10/05/2018 12:07
13
EBS
10/05/2018 12:10
14
EBS
10/05/2018 13:49
Video 50135 2018-02-21 Frontend development. Ole with the most experience on the topic takes the lead. 07:10 (Elias is driver) Ole: And i feel you need a space between those … Elias: Here? (Does as instructed in the code) Ole: No, further down Elias: Here (tries to type somewhere else) Ole: Yes there, well no not like that Christian: Between parentheses Elias: Oh like that, I see. Not “newline”, but space
Video 110135 2018-02-21 04:42 (Elias is driving) Ole(points on the screen): Could you take space with the equals? Elias: I was on my way there Ole: Okay, nice. Because I like this a bit more. Just like.. Christian: Space there too. On the bottom Ole: Mhm Elias (types as instructed) Ole: Newline was what he wanted. Before “Component did mount” Elias (slightly bothered) : Ah okay. Space, newline. They blend into each other
16:20 (Ole is still the driver) Ole(after some googling): It says here that it’s recommended to use selectors, and not the state directly Elias: I absolutely believe that Christian(seems tired, rubs his eyes): Selectors are so easy to implement. We have at least had great success with it earlier, so I suggest we do something like that Ole: Okay, do you guys want to try? Christian: I think it’s Elias’ turn? I suggest a coffee before we continue. (The team takes a break before continuing with the problem. )
Reports\\Coding Summary By Node Report
Page 8 of 62
APPENDIX C. THEMES FROM ANALYSIS
54 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
15
EBS
10/05/2018 13:55
Ole(keeps searching) Christian: It was fast too Elias: This was fast, Ole. Elias(jokingly): This is like it’s meant to be Ole(refers to the source in which he’s reading): The worst is that some people here say “take the number, and add an empty string”. (Everyone laughing) Elias: Which is what I did. Christian: The hack is the way to go? Elias: Yes, but that is because. Had it been another programming language which had static types, had it been Typescript Christian: Then you could have converted it to a string. But here you just have to say that Ole(interrupts): Ehm. Elias, Elias, Elias, Elias. You know what we’ll do? Which is just a significantly more pretty way to do it. Don’t write that string and a plus, but take… Ole(gestures towards screen): if you remove that.. Elias: Could you tell me what you’re planning to do? Ole: Yes, just take dot to-string. Elias. Could I do that here? Ole: Yes
Nodes\\Code quality Document Internals\\2018-02-20_ Sprint retrospective No
0.0214
1 1
EBS
17/04/2018 14:58
1
EBS
17/04/2018 15:09
The code quality has been good overall
Internals\\2018-03-06_Sprint retrospective No
0.0502
1
We were in general good at fixing things that we wanted to improve from previous days and sprints
Internals\\2018-04-18_Sprint retrospective No
0.1071
1 1
EBS
12/05/2018 12:04
We are getting familiar with the technology in which we work. Instead of many hours of research to how to do things, we know what to do. We also are able to improve and refactor naive solutions at times
Reports\\Coding Summary By Node Report
Page 9 of 62
APPENDIX C. THEMES FROM ANALYSIS
55 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
14/05/2018 15:26
Internals\\Christian Echtermeyer Diary No
0.0276
1
I think the project is moving along nicely now and i think we will be able to present something decent at the first sprinte review, although time might be a limitation considering it will get busy with the other courses towards the end of the sprint.
Internals\\Daily retrospectives No
0.0251
5 1
EBS
17/04/2018 13:49
2
EBS
11/05/2018 18:37
3
EBS
17/04/2018 14:27
4
EBS
17/04/2018 14:54
We set a good standard for naming convention and formatting swiftly
What needs improvement? Comment code Can be improved by: Write documentation on every method when making them
Refactor smelly code
We followed the lean principle. When attempting to implement an unneeded method, we stopped. 5
EBS
17/04/2018 14:54
1
EBS
23/04/2018 12:46
Keep making choices that give value to the project. Lean!
Internals\\Elias Sørensen Diary No
0.0889
3
I had mixed experiences of the first day of mob programming. I felt at times that we had progress considering that we right there and then made a decent naming convention, and formatting was immediately set to our preference because we debated how it was supposed to be. At times however, as driver, I felt that the navigators maybe took a bit too much detailed control. 2
EBS
23/04/2018 13:03
Navigation went well, and I am also starting to get used to being navigated. I also feel the code quality of the day was nice, and we god more than acceptable naming conventions almost immediately. We are ahead of schedule, which feels really motivating. 3
EBS
23/04/2018 13:05
We made productive, working code, and I noticed that mostly, syntax errors were discovered instantly. Also, we had good naming conventions, and solved most problems that occured, rather swiftly. I got really frustrated with the error we had, but finally solving it was satisfying.
Reports\\Coding Summary By Node Report
Page 10 of 62
APPENDIX C. THEMES FROM ANALYSIS
56 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
14/05/2018 15:27
Internals\\Ole Kristian Aune Diary No
0.0355
1
We implemented all rest api endpoints for user and added lots of tests. It all went really smooth and collaboration worked really good. No major set backs and lots of progress. All in all very happy with how smooth the system worked today.
Internals\\Video transcriptions No
0.3985
18 1
EBS
10/05/2018 11:31
Video70124 2018-02-05 10:40 ( The timer beeps for switch while the team discusses folder and package structure, and Elias and Ole switch places. The switch seems to break the work flow. Elias becomes the new driver) Ole: Who is it? Christian: But we need the package first, it’s you Elias Elias: It’s me? Okay. Elias: Then we continue where we left off. Now it’s no longer me who decides what happens Christian: You can still participate in the decision making Elias: Yeah, I’ll come with input and discussion, but uh. Christian: We must have a “data” folder? Elias: But that doesn’t need to lay under “rest”. Christian: It’s not under “rest” now, it’s made under Elias: Data? Ole: What is data? Elias: Data-classes. It’s models. You could say it’s the data representation in the language of.. Christian: You could make a mock folder instead of data, because we technically don’t make data classes now. Or do we make data classes, only that we have a mock object in the data classes? *Keep discussing name conventions from REST documentation*
Reports\\Coding Summary By Node Report
Page 11 of 62
APPENDIX C. THEMES FROM ANALYSIS
57 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
2
EBS
10/05/2018 11:38
16:11(Elias is driving) 2018-02-05 Elias: Should we make members first, or should we make parameters first? Christian: We could make members Ole: We can find out what we need. Christian: I think with members, it’s the same thing really. Christian: String “name”... Christian: That doesn’t make sense Elias(With a confused look): Type? Christian: Type, maybe Elias (asks Ole): Or does it make sense to have an Enum for type? Ole: Uuuhm.. yeah maybe Elias: Enum, i think enum could be smooth Christian(interrupts): Noo, the enum will be so damn large, there are hundreds of objects. Ole: And besides Elias: We must have a register for types somewhere, with string we could compare it directly to Ole: Hmm… Ole: What is it we want “roadobject” to be? Elias: We have defined some stuff in the uuh… issue, haven’t we? (A few second pause) Ole: I am trying to ask the question now; what is it “roadobject” should do? Elias: Roadobject should fetch data from the database, cache that, and then we could retrieve what we need. Christian: What we have defined on beforehand is type and area, hence position, basically. That is the most basic of a roadobject Elias(types): Should we go for this then? Elias: But area, what was that, that would then be a...? Christian: A position, then. Christian. But how do we define a position? Elias: It could be a list, or we could make an own class for position, with “get lat” and “get long” or whatever. Ole: I actually think that a class for that is nice. Christian: I support that Elias: Should we just make it then? 3
EBS
10/05/2018 11:45
2018-02-15 Video0129 16:36 Elias: And then we say that “srid” instead is… that’ an int actually *Elias and Ole are laughing* Ole: Int and long and… Elias: Well look at that Ole: Yeah, here there is no consistency Elias: It was late in the night okay? Ole: Yeah, that’s allright. That is very good. I was ill, so.
Reports\\Coding Summary By Node Report
Page 12 of 62
APPENDIX C. THEMES FROM ANALYSIS
58 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
4
EBS
10/05/2018 11:46
22:54 (Ole is back from being ill, Christian and Elias have been pair programming a couple of days) Elias: We branched out from the report...ap.. uuh branch I think. Ole: But why did you do that? Elias: I don’t remember why we did it, but i believe there was a good reason Christian: Was it that the newest updated Elias: I think we had.. Ole: Yeah, but you don’t want to, if you’ve done stuff i one function, you don’t want it in the branch of another function Elias: No you don’t want that. But there was, I think there was Ole: You’ll want to branch out from master when you make a new feature Elias. But I think there was a reason. Christian: I think there was something that wasn’t done, so it wasn’t ready to merge into master. Ole: Yeah, but then you still don’t want to do that Elias(agrees): You still don’t want take it further. Elias: I don’t remember the reason, but there was something we did that made us want that. Christian: Yeah there was a reason. Ole: You want to have it completely separated. Elias: There was something, some kind of dependency we didn’t want… Ole: If, if there’s something that you’ve updated that you want in the new branch, then you make a pull request for only that function, merge it into master, and make a new branch from master. New functions should always go out from master. Elias: Yeah, so that report stuff shouldn’t have been in this branch at all Ole: No, it shouldn’t have been here. Because it doesn’t belong to this branch at all Elias: Yeah, it’s not related to “get roadobjects”. Christian: It could also be that we forgot it. Elias: Yeah we could’ve forgotten it for all I know. Elias: The question now is what we do with it then Ole: We’ll just let it be like this now. We’ll just don’t do it.. Elias: ...in the future, yes. 5
EBS
10/05/2018 11:49
Video 20129 2018-02-15 06:35: (Discussion about defining GET, which is known as standard method) Ole: It’s standard everywhere. It’s the reason why fetch in javascript, if you don’t define anything, is a get-request. Elias: Mm Elias: I still like that it’s explicitly GET, and POST and PUT 6
EBS
10/05/2018 11:52
13:10: 2018-02-15 (Ole notices a mistake while Elias is typing, but seems like he tries to hold back) Ole *Exhales*, then mutter under his breath: Elias, Elias, Elias. Elias *Whispers*: I can see it Elias: I don’t usually write that. I let a parsing program handle it. Ole: We haven’t set up a good parser here. 7
EBS
10/05/2018 11:53
Video 90129 2018-02-15 17:00 (Switching driver from Elias to Christian.The test just implemented fails.) Ole: Run the rest. Did we run the other test? Elias: No Ole: Then let’s run that one too. Ole: Okay, it failed Christian: It failed Elias: Boys, should we take a break? Ole: Soon, we’ll just make this one not fail. Christian: Why isn’t this equal? Elias: I think it’s because we must implement equals Ole: In user. Elias: In user Ole: On a user Elias: On a user Elias: Implement equals Ole: Generate Reports\\Coding Summary By Node Report
Page 13 of 62
APPENDIX C. THEMES FROM ANALYSIS
59 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
8
EBS
10/05/2018 11:57
EBS
10/05/2018 12:07
EBS
10/05/2018 12:08
Video 40135 13:05 (Christian is driving) Ole: Then we can here, If you just remove all the content in “App” Christian: Don’t we just want to remove the header? Add it where our header stands instead Ole: Yeah you can do that Elias: And you can.. Ole and Elias simultaneously: Then you write header Elias: With uppercase H yes Christian(typing as instructed) Ole: And then.. Naah not quite, you need Elias: Self-closing Ole: Yes, so a slash, and then close. Elias: And it’s normal to have a space after… before the slash. Ole: Yes, that’s normal convention Christian(finishes typing): Like that Ole: Yes, so that’s a self-closing tag. 9 Video 50135 2018-02-21 Frontend development. Ole with the most experience on the topic takes the lead. 07:10 (Elias is driver) Ole: And i feel you need a space between those … Elias: Here? (Does as instructed in the code) Ole: No, further down Elias: Here (tries to type somewhere else) Ole: Yes there, well no not like that Christian: Between parentheses Elias: Oh like that, I see. Not “newline”, but space 10 07:54 (Elias is still the driver) 2018-02-21 Ole: This dot props dot children Christian: What is it we’re doing now, could you explain it? Ole: Yes. What we do now is that we make a component that is a wrapper component. So actually all we want from this is that all we put extend from view from now on, Christian: will be added into that section? Ole: Yes, will be added, because all that will be children, so, to the view component. Christian: mhm Ole: So the only advantage we get from this is that we can add a styling, a css in here that specifically styles classname “view”, so all views have a base styling. 11
EBS
10/05/2018 12:09
Video 90135 2018-02-21 15:33 (Elias is the driver) Elias (showing a code line) : Is it better to have it like this? Or not Ole: In that case make it consistent, because it’s not that way above Christian: Just don’t do it instead Ole: No, don’t do it, because that’s often known as a deconstructing way to write it. If you deconstruct an object you have spaces between the edges, while if you make it you don’t.
Reports\\Coding Summary By Node Report
Page 14 of 62
APPENDIX C. THEMES FROM ANALYSIS
60 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
12
EBS
10/05/2018 13:12
2018-04-24 Mob programming late in the process. Video 0168_1 05:12 (Implementing a new flow in the submit part of application. Christian is driver) Christian: But what is the goal of this? Elias: The goal is that we… Ole: Confirmation dialog Elias: That we add stuff into the state, and when we press “create case”, then we can fetch that data from the state and add it Christian: So should it pop up a window “create case” with reports “blablabla”, text “blablabla” and then, confirm? Or cancel? Elias: No...more like Ole and Elias in unison: You have done it. Christian(silent, thinking) Elias: You have done it, this is the case that was made, and then you can see the case in a table. See details of the case, or make a new one. That you have a few choices and get navigated. Christian: I can imagine a confirmation dialog when you make the case. Elias: Are you sure you want to make that? Christian: Yes Elias (spells out imagined text in UI): This is the case you are now creating? Ole: mhm Elias(pauses, thinking): It is possible. But it’ll be an extra navigation too. If it’s easy to change stuff, then it’ll maybe be just as well Ole: It’s just that we change what is called where. So if you make it there you add it to the state. Elias and Christian: mhm Elias: And then you get up a dialog with confirm, or “Ok” has the “submit” Ole: Mhm, because, right, if you press “add to case”, then the reports are added to case. So the only thing “Create Case” must do is, the button, is to add the text, and maybe user info if you’re logged in, into the state. Elias: And, and that is maybe natur… Ole(keeps explaining, interrupts): and that is accessed in the dialog, and then you confirm, and then everything is sent in. Elias: I think that’s actually more natural, because the you “build” the case so that it’s like Elias(gesticulates to the current UI element): Here you have the raw data, and we build a case like it’s supposed to look like. That could be natural to do Ole: It could get done 13
EBS
10/05/2018 13:16
Christian: Then we could actually had the text in the window, or would that be weird? Elias: I don’t quite understand what you mean by that Ole: But that will be shown when you take the.. Elias(interrupts): mhm, then it will be shown like a text, then it won’t be shown like an input box, then it will be shown like a text. So that, if you now. What we’re thinking now is that “create case” does not call directly on “submit”, that’s what the dialog should do instead. So “Create Case” is just supposed to add Elias(gesticulating with hand): the items we have into the state in “Current Case” Ole: Yes, the only thing we actually add right now is the text. Elias: mhm Ole: Because the case is already added. Elias: Yes, it will be added when you press those buttons. But what we can start with is that we can make an action that’s called “add text”... “to case”? (pauses) Elias: And then we can receive that action in the “reducer” after. Elias(explains and navigates Christian): So if you go into actions dot js, that’s in the panel here, then you can make a new one that’s called. Christian(starts working) Elias: You can copy that one, yes. (A few seconds pause while Christian is writing) Ole: I don’t like that it lies right there..
Reports\\Coding Summary By Node Report
Page 15 of 62
APPENDIX C. THEMES FROM ANALYSIS
61 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
14
EBS
10/05/2018 13:19
Video 0169_1 2018-04-24 06:02 (Ole is the driver. The team has trouble with search fields in a table) Elias: Huh? What happens if you search on date updated, then? Ole(types on keyboard, searches) Elias(chuckles) Christian: What’s up Elias: Nah, the search is weird Christian: Agree Elias: Is there any, is there any lacking.. I think I know where the error might be. Ole: Okay? Elias: I think it could be lacking consistency between the number of searchable items, and the number of columns. Because we’ve copied this table from an entirely different place. So it could be that that’s why...because what it seems like now is that, maybe the reason why it’s undefined is because there isn’t any column that consists.. Christian: Right. But which “View” are you in now? Elias and Ole: Cases Christian: Okay, that makes sense. Because I believe the react table searches for reports, not cases. Elias(slightly doubtful): Yeah… (Few seconds pause) (At this point Christian turns to his computer) 15
EBS
10/05/2018 13:20
Elias(reads code out loud): Filter dot ID. Filter dot value. So that’s the way we searched in the report table. But it’s probably not similar here. Elias: Could you check what it’s like in the report table? I just want to understand how we’ve implemented it Ole(shows in code): Here’s an own filter method for this one. Elias: Yeah Ole: For date Elias: mhm Ole: We might have to have that here too Elias: So we must Ole: Was it this? Yes. (clicks) Ole: We don’t have it on both.. Elias: That could… fuck things up. Have it on both. Sort-method and filter-method Ole: Why is this indented so strangely? Elias: try. Try-catch Ole(clicks): I’m just trying to figure out… (A few seconds pause while Ole is typing) Elias: What are you doing? Ole: It worked Elias: Now you found cases. Ole(typing) Elias: I don’t understand. What happens if you type in the user field? Write four there. Ole(types as instructed) Elias(reacts to result): Ho-how! That’s pretty fucked up. Elias: All of them are “filterable”. Uhm...shouldn’t maybe...shouldn’t we have an own filter-method on each column? (They keep trying to solve the problem) 16
EBS
10/05/2018 13:51
24:53 (Closing in on the fix) Elias: So. There’s something.. I think it is because it’s not exactly like: That it isn’t Ole: Could you print what those things are? Elias: Yes Ole: Just console log a bit above. Elias(typing) 26:29 (Elias has printed the whole thing to check the values) Elias: So, here they are alike. For some reason, it evaluates them to be not like.
Reports\\Coding Summary By Node Report
Page 16 of 62
APPENDIX C. THEMES FROM ANALYSIS
62 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
17
EBS
10/05/2018 13:53
(Continuing to fix the search issue, Elias is still driver) Elias(refers to searching for the number 300 while the item is 300 too): Here we have 300 and 300 Ole: You have 300 longer up too. Elias: Woho! It worked then. Ole: Like ish Elias: Maybe we should take “contains” then Ole: Yes, that’s what I’m thinking. 18
EBS
10/05/2018 13:55
Video 10169_1 2018-04-24 01:30 Elias: A number can’t contain another number. The thing is that we must convert them to strings. We musk make sure the numbers are strings. Couldn’t we say.. how Ole: I’ll look it up. Elias: I have a way meanwhile. A quick-fix. Elias(refers to what he’s typing on screen): You take that plus that Elias(laughs): Ole(glances at the screen): No Elias(smiling): This is a hack. Just to check that the.. Christian: I don’t think that will work Elias(keeps typing): Why won’t it work? It is a string now. Christian(laughing): This is fricking hacky Elias(typing and running the result): He-he-heyyyy Christian and Elias (laughing) Ole(shakes his head) Elias: The problem is that we’re searching with number equals number. If we don’t have any static types in javascript, we just have to hack around a string. Elias(keeps laughing) Christian: Well yes Elias: This worked Christian: It worked pretty well, too. Elias(laughing some more and takes a sip of coffee) Ole(keeps searching) Christian: It was fast too Elias: This was fast, Ole. Elias(jokingly): This is like it’s meant to be Ole(refers to the source in which he’s reading): The worst is that some people here say “take the number, and add an empty string”. (Everyone laughing) Elias: Which is what I did. Christian: The hack is the way to go? Elias: Yes, but that is because. Had it been another programming language which had static types, had it been Typescript Christian: Then you could have converted it to a string. But here you just have to say that Ole(interrupts): Ehm. Elias, Elias, Elias, Elias. You know what we’ll do? Which is just a significantly more pretty way to do it. Don’t write that string and a plus, but take… Ole(gestures towards screen): if you remove that.. Elias: Could you tell me what you’re planning to do? Ole: Yes, just take dot to-string. Elias. Could I do that here? Ole: Yes
Reports\\Coding Summary By Node Report
Page 17 of 62
APPENDIX C. THEMES FROM ANALYSIS
63 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
17/04/2018 14:59
Nodes\\Cooperation Document Internals\\2018-02-20_ Sprint retrospective No
0.0840
1
2. Didn’t always follow the clock 3. We could switch more often when someone has an idea. The driver should not navigate himself. Generally switching driver
Internals\\2018-03-06_Sprint retrospective No
0.2996
2 1
EBS
17/04/2018 15:08
2
EBS
14/05/2018 13:45
We got better at both navigating and driving
More focus on letting the driver do things the way he wants and correct afterwards. Dont scream out mistakes as soon as they appear, often the person writing knows they are there and will fix them anyway. How could we fix it: This can be achieved by first telling the driver the goal of the work session. Instead of guiding for every line. This means the driver knows what to do and can work fairly independently instead of being forced to write every line by listening to others. This gives more freedom and prevents annoyance.
Internals\\2018-04-18_Sprint retrospective No
0.1339
1 1
EBS
13/05/2018 13:01
We felt that the roles in pair programming weren’t as distinguishable as in mob. When in pair, there was more a back and forth discussion of the development, while in mob, the driver has more than enough with catching all the commands from the navigators
Internals\\Christian Echtermeyer Diary No
0.0265
2 1
EBS
14/05/2018 13:45
Things that did not go well: There was some small micromanagement or something similar which got on my nerves slightly once, but nothing significant 2
EBS
14/05/2018 13:45
There was a bit of micromanaging which got on my nerves a little but nothing too good or bad
Reports\\Coding Summary By Node Report
Page 18 of 62
APPENDIX C. THEMES FROM ANALYSIS
64 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
0.1250
14
Reference Number
Coded By Initials
Modified On
1
EBS
14/05/2018 13:45
2
EBS
14/05/2018 13:45
3
EBS
14/05/2018 14:15
Internals\\Daily retrospectives No
The navigators shouldn’t micromanage the driver
The navigators shouldn’t micromanage the driver If driver notices this, say so Navigators should try to adapt based on the type of work We think we should get better at this later
When we have made an agreement, commit to it Make sure everyone is motivated We must not absolutely be the whole team there. If one person wants to leave or take a small break, do it. If we’ve planned a late night, set time aside for dinner We are of course allowed to get tired and sick of working, but not necessary to complain too often, as this demotivates the rest of the team 4
EBS
14/05/2018 13:45
Navigation worked better than yesterday, we seem to be learning already the basics of each others quirks 5
EBS
17/04/2018 14:04
6
EBS
17/04/2018 14:26
7
EBS
14/05/2018 13:45
8
EBS
17/04/2018 14:27
9
EBS
17/04/2018 14:27
10
EBS
14/05/2018 13:45
Navigating worked well. Good level of abstraction.
Good cooperation between driver and navigators
Avoid micro managing! typos as navigator
Navigator explain where to fix stuff
Describe where to fix stuff using line numbers
The times we remembered to use line numbers to refer where in the code we were, things were easier for the driver Navigators do not micromanage the driver to the same extent 11
EBS
11/05/2018 21:45
What needs improvement? We need to improve how we explain what we’re thinking. The driver needs to understand what you wish to do. Can be improved by: Explain the end goal, the context and concept of what we are going to do, before stating code. Discussion of naming variables sometimes breaks the flow we’re in 12
EBS
17/04/2018 14:28
How can we improve this? Explain the end goal, the context and concept of what we are going to do, before stating code. Keep names in mind, but save it to a more fitting time.
Reports\\Coding Summary By Node Report
Page 19 of 62
APPENDIX C. THEMES FROM ANALYSIS
65 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
13
EBS
17/04/2018 14:29
Keep trying to get better at navigating. Be aware of what you’re saying, referring to line numbers, explain concepts. 14
EBS
17/04/2018 14:42
1
EBS
14/05/2018 13:45
We were driving for too long
Internals\\Elias Sørensen Diary No
0.1744
5
I had mixed experiences of the first day of mob programming. I felt at times that we had progress considering that we right there and then made a decent naming convention, and formatting was immediately set to our preference because we debated how it was supposed to be. At times however, as driver, I felt that the navigators maybe took a bit too much detailed control. This happened because I had a way I usually generated code, but they were used to another. After learning my teammates’ way however, that specific conflict might not happen again. I learned something new about the java editor, but the flow broke. 2
EBS
23/04/2018 13:00
2018-02-22 Today we implemented a menu for front-end, and then added a simple redux structure. Programming went well today. Like the other days this week, I felt kind of tired in the end of the day. I felt programming went well, and we were able to produce decently. I think we were able to navigate well. 3
EBS
23/04/2018 13:03
Navigation went well, and I am also starting to get used to being navigated. I also feel the code quality of the day was nice, and we god more than acceptable naming conventions almost immediately. We are ahead of schedule, which feels really motivating. 4
EBS
23/04/2018 13:06
I felt like today was an awesome day. Progress is easily noticed on front-end. Driving and navigating also feels better than earlier. We have started stating line numbers when the driver is trying to find where in the code the navigator is looking. That makes it a lot easier to find said code block when I’m the driver 5
EBS
23/04/2018 13:07
I also feel we are getting better at navigating at the correct abstraction, in other words not pointing out mistakes at once, but making the driver aware of them if needed after he’s done typing. We also let the driver take more control when he knows what to write to a greater extent.
Internals\\Ole Kristian Aune Diary No
0.0314
1 1
EBS
14/05/2018 14:14
At times there was some frustration and negative vibes, but we pulled through and got a lot done. We still need to get better at communication / explaining what we mean, and be patient when explaining to others.
Reports\\Coding Summary By Node Report
Page 20 of 62
APPENDIX C. THEMES FROM ANALYSIS
66 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
0.1180
8
Reference Number
Coded By Initials
Modified On
1
EBS
14/05/2018 13:45
2
EBS
14/05/2018 13:45
Internals\\Video transcriptions No
03:38: (Both Ole and Elias cry out as soon as Christian types something wrong. ) Elias: Spacing Ole: You must have spacing there Christian: I will fix it after
13:10: 2018-02-15 (Ole notices a mistake while Elias is typing, but seems like he tries to hold back) Ole *Exhales*, then mutter under his breath: Elias, Elias, Elias. Elias *Whispers*: I can see it Elias: I don’t usually write that. I let a parsing program handle it. Ole: We haven’t set up a good parser here. 3
EBS
10/05/2018 11:57
4
EBS
14/05/2018 13:45
5
EBS
10/05/2018 12:07
Video 40135 13:05 (Christian is driving) Ole: Then we can here, If you just remove all the content in “App” Christian: Don’t we just want to remove the header? Add it where our header stands instead Ole: Yeah you can do that Elias: And you can.. Ole and Elias simultaneously: Then you write header Elias: With uppercase H yes Christian(typing as instructed) Ole: And then.. Naah not quite, you need Elias: Self-closing Ole: Yes, so a slash, and then close. Elias: And it’s normal to have a space after… before the slash. Ole: Yes, that’s normal convention Christian(finishes typing): Like that Ole: Yes, so that’s a self-closing tag.
25:31 (Christian is still driver) Christian: We put this in “App” didn’t we? No, I don’t remember Elias: No I don’t think we did that Christian: No, then let’s do that Elias: Import menu Christian (types the norwegian word for menu): “Meny” Elias: “Meny”, *then laughing* Ole: That would have worked that too, though Christian: I don’t think so Ole: Yes Elias: Because you must call, Elias(refers to a code line): here you define what you call it
Video 50135 2018-02-21 Frontend development. Ole with the most experience on the topic takes the lead. 07:10 (Elias is driver) Ole: And i feel you need a space between those … Elias: Here? (Does as instructed in the code) Ole: No, further down Elias: Here (tries to type somewhere else) Ole: Yes there, well no not like that Christian: Between parentheses Elias: Oh like that, I see. Not “newline”, but space
Reports\\Coding Summary By Node Report
Page 21 of 62
APPENDIX C. THEMES FROM ANALYSIS
67 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
6
EBS
10/05/2018 13:16
Christian: Then we could actually had the text in the window, or would that be weird? Elias: I don’t quite understand what you mean by that Ole: But that will be shown when you take the.. Elias(interrupts): mhm, then it will be shown like a text, then it won’t be shown like an input box, then it will be shown like a text. So that, if you now. What we’re thinking now is that “create case” does not call directly on “submit”, that’s what the dialog should do instead. So “Create Case” is just supposed to add Elias(gesticulating with hand): the items we have into the state in “Current Case” Ole: Yes, the only thing we actually add right now is the text. Elias: mhm Ole: Because the case is already added. Elias: Yes, it will be added when you press those buttons. But what we can start with is that we can make an action that’s called “add text”... “to case”? (pauses) Elias: And then we can receive that action in the “reducer” after. Elias(explains and navigates Christian): So if you go into actions dot js, that’s in the panel here, then you can make a new one that’s called. Christian(starts working) Elias: You can copy that one, yes. (A few seconds pause while Christian is writing) Ole: I don’t like that it lies right there.. 7
EBS
10/05/2018 13:20
Elias(reads code out loud): Filter dot ID. Filter dot value. So that’s the way we searched in the report table. But it’s probably not similar here. Elias: Could you check what it’s like in the report table? I just want to understand how we’ve implemented it Ole(shows in code): Here’s an own filter method for this one. Elias: Yeah Ole: For date Elias: mhm Ole: We might have to have that here too Elias: So we must Ole: Was it this? Yes. (clicks) Ole: We don’t have it on both.. Elias: That could… fuck things up. Have it on both. Sort-method and filter-method Ole: Why is this indented so strangely? Elias: try. Try-catch Ole(clicks): I’m just trying to figure out… (A few seconds pause while Ole is typing) Elias: What are you doing? Ole: It worked Elias: Now you found cases. Ole(typing) Elias: I don’t understand. What happens if you type in the user field? Write four there. Ole(types as instructed) Elias(reacts to result): Ho-how! That’s pretty fucked up. Elias: All of them are “filterable”. Uhm...shouldn’t maybe...shouldn’t we have an own filter-method on each column? (They keep trying to solve the problem) 8
EBS
11/05/2018 12:25
Ole(interrupts): Ehm. Elias, Elias, Elias, Elias. You know what we’ll do? Which is just a significantly more pretty way to do it. Don’t write that string and a plus, but take… Ole(gestures towards screen): if you remove that.. Elias: Could you tell me what you’re planning to do? Ole: Yes, just take dot to-string. Elias. Could I do that here? Ole: Yes
Reports\\Coding Summary By Node Report
Page 22 of 62
APPENDIX C. THEMES FROM ANALYSIS
68 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
14/05/2018 10:40
1
EBS
12/05/2018 12:03
Nodes\\Fatigue Document Internals\\2018-02-20_ Sprint retrospective No
0.0369
1
8. Take breaks or switch tasks when we’re stuck on a train of thought
Internals\\2018-04-18_Sprint retrospective No
0.0688
1
We notice that we’re used to the workflow. We don’t get exhausted like earlier, something also noticed a bit before this sprint.
Internals\\Christian Echtermeyer Diary No
0.0616
2 1
EBS
12/05/2018 09:21
Our work didn't start before around 12:30 due to working on another project (CCD) and therefore we decided to work untill 18:00. I am very exhausted after todays work, maybe because it is monday, maybe because we worked late just setting things up which i am not a fan of. I feel the team worked well today and we got work done, although my mood was declining towards the end and did not match my fellow teammates. 2
EBS
12/05/2018 09:24
My experience of the day was fairly good, although feeling slightly tired towards the end of the day the mood was good and the team worked well
Internals\\Daily retrospectives No
0.0471
5 1
EBS
14/05/2018 10:38
When we have made an agreement, commit to it Make sure everyone is motivated We must not absolutely be the whole team there. If one person wants to leave or take a small break, do it. If we’ve planned a late night, set time aside for dinner 2
EBS
17/04/2018 13:59
We are of course allowed to get tired and sick of working, but not necessary to complain too often, as this demotivates the rest of the team 3
EBS
14/05/2018 10:39
We should have planned breaks, as well as taking them when we are tired. Possibly a tally system on the board to make it physical.
Reports\\Coding Summary By Node Report
Page 23 of 62
APPENDIX C. THEMES FROM ANALYSIS
69 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
4
EBS
17/04/2018 14:16
5
EBS
17/04/2018 14:16
We are tired after the day
Try to have an “own time” during the day, where we can collect our thoughts! This to avoid having to be “on” all the time.
Internals\\Elias Sørensen Diary No
0.0300
1 1
EBS
23/04/2018 13:00
2018-02-22 Today we implemented a menu for front-end, and then added a simple redux structure. Programming went well today. Like the other days this week, I felt kind of tired in the end of the day. I felt programming went well, and we were able to produce decently. I think we were able to navigate well.
Internals\\Ole Kristian Aune Diary No
0.1982
4 1
EBS
14/05/2018 13:46
I felt really good going into the day today, but after a long day of work (ending now at 18) i feel really exhausted. Also my back hurts. It may be because we are constantly changing chairs and forgetting to configure them for our need, or it may just be a bad chair. If this continues, we may have to find another arrangement to prevent this. 2
EBS
23/04/2018 14:31
Today was a bit less productive than yesterday. We tried fixing some problems with our continuous integration setup. Made frontend tests actually fail when a test fails and started speeding up backend testing. I felt tired most of the day, and my productivity was influenced by it and may also have affected the rest of the team. To sum up, we made some progress, but it wasn’t as productive as I would have liked it. 3
EBS
23/04/2018 14:32
We wanted to speed up the testing time with CI, and started figuring out what we could cache for speedier integration tests. We managed to get it working locally, but ended day with error on travis. A bit of a confusing and hard day, but we managed to stay motivated most of the time. Some became a little bit of zombie programming at times today 4
EBS
23/04/2018 14:36
A little tired as usual at the end of the day, but all in all a good day. Unfortunately we have some problems with videotaping, but it was the right decision not to use time on it, and instead keep pushing the project forward
Reports\\Coding Summary By Node Report
Page 24 of 62
APPENDIX C. THEMES FROM ANALYSIS
70 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
0.0920
8
Reference Number
Coded By Initials
Modified On
1
EBS
10/05/2018 11:53
2
EBS
10/05/2018 12:11
3
EBS
10/05/2018 12:13
Internals\\Video transcriptions No
Video 90129 2018-02-15 17:00 (Switching driver from Elias to Christian.The test just implemented fails.) Ole: Run the rest. Did we run the other test? Elias: No Ole: Then let’s run that one too. Ole: Okay, it failed Christian: It failed Elias: Boys, should we take a break? Ole: Soon, we’ll just make this one not fail. Christian: Why isn’t this equal? Elias: I think it’s because we must implement equals Ole: In user. Elias: In user Ole: On a user Elias: On a user Elias: Implement equals Ole: Generate
Video 120135 2018-02-21 No major incidents. Noticed fatigue and need for a break.
Video 140135 2018-02-21 03:23 (Driver switch Christian to Elias. The team has spent more than an hour struggling with a test that won’t run due to issues with rendering. ) Elias (while switching seats): I feel tired Christian: So do we all Elias: What if we work a little bit more with this, and if we’re stuck, then we make the wiki, and then come back to it. Ole: mhm Christian: Until half past. It’s not much but... Elias: Let’s try 8 minutes more to wrestle with this, and if it won’t work we’ll take a break from this and work with something else. Ole(proceeds with the problem at hand): Let’s test something.. 4
EBS
14/05/2018 09:57
5
EBS
12/05/2018 12:01
(Christian is writing report, Ole and Elias are pair programming) Ole (regarding Docker, talking to Christian): You miss this don't you Elias: Run it Ole: Do you miss this (once again talking to Christian) Christian: Hmm? (Looks at screen) Christian: No (smiles)
Elias: Is there any, is there any lacking.. I think I know where the error might be. Ole: Okay? Elias: I think it could be lacking consistency between the number of searchable items, and the number of columns. Because we’ve copied this table from an entirely different place. So it could be that that’s why...because what it seems like now is that, maybe the reason why it’s undefined is because there isn’t any column that consists.. Christian: Right. But which “View” are you in now? Elias and Ole: Cases Christian: Okay, that makes sense. Because I believe the react table searches for reports, not cases. Elias(slightly doubtful): Yeah… (Few seconds pause) (At this point Christian turns to his computer)
Reports\\Coding Summary By Node Report
Page 25 of 62
APPENDIX C. THEMES FROM ANALYSIS
71 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
6
EBS
10/05/2018 13:21
7
EBS
10/05/2018 13:49
13:02 (Christian starts paying attention again, and joins the discussion) Christian: Let me see Elias: On fetch data Christian: That one’s a bit brutal. (Pause) Christian: Can’t you just filter the state instead of “getting” every time? Ole(types something): I must just see what happens if we do like this Elias: Then we get no data? Christian: Huh Ole: What does it do, that on fetch…(types the rest) (Around half a minute silence, everyone checks their phones, do their own thing) (Elias leaves the room while silence continues. Ole seems to do some searching)
16:20 (Ole is still the driver) Ole(after some googling): It says here that it’s recommended to use selectors, and not the state directly Elias: I absolutely believe that Christian(seems tired, rubs his eyes): Selectors are so easy to implement. We have at least had great success with it earlier, so I suggest we do something like that Ole: Okay, do you guys want to try? Christian: I think it’s Elias’ turn? I suggest a coffee before we continue. (The team takes a break before continuing with the problem. ) 8
EBS
12/05/2018 12:02
( The team continues, Elias is now driver. . Ole sits in the low armchair in the corner instead of by one of the navigator computers.) Ole: I’ll sit here. Contribute a bit from here. Elias: I suggest.. Ole(stands up and fetches his glasses from the table. : Mhm? Elias: That we make an own filter-method on this. Or at least fix to accessor is right, because.. Ole(Sits down again): Yes, go ahead!
Nodes\\Knowledge Transfer Document Internals\\2018-02-20_ Sprint retrospective No
0.0743
2 1
EBS
11/05/2018 21:10
EBS
13/05/2018 15:43
We got better to adapt navigation, as well as understanding each other better as driver. 2 We learn much more about setup and new technologies
Reports\\Coding Summary By Node Report
Page 26 of 62
APPENDIX C. THEMES FROM ANALYSIS
72 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
13/05/2018 12:59
Internals\\2018-03-06_Sprint retrospective No
0.2762
1
More focus on letting the driver do things the way he wants and correct afterwards. Dont scream out mistakes as soon as they appear, often the person writing knows they are there and will fix them anyway. How could we fix it: This can be achieved by first telling the driver the goal of the work session. Instead of guiding for every line. This means the driver knows what to do and can work fairly independently instead of being forced to write every line by listening to others. This gives more freedom and prevents annoyance.
Internals\\2018-04-18_Sprint retrospective No
0.1061
1 1
EBS
13/05/2018 15:43
We are getting familiar with the technology in which we work. Instead of many hours of research to how to do things, we know what to do. We also are able to improve and refactor naive solutions at times
Internals\\Christian Echtermeyer Diary No
0.1367
5 1
EBS
13/05/2018 15:43
I think tomorrow will be a easier day as we finally get to work on some slightly more interesting things. Generally todays productivity felt alright. We hit a lot of errors, mainly due to setting up the project being new to all of us. 2
EBS
13/05/2018 15:43
Today we worked more or less only on trying to set-up caching for the continuous integration with travis. We had varying degrees of sucess on this front, we managed so set it up for local caching but the CI tests on travis still dont cache properly and it seems to be very tough to fix. 3
EBS
13/05/2018 15:43
22.02.2018 Today we worked once again on front-end. The work seemed a lot slower than yesterda simply judging by the progress, but it may have been affected by once again learning new technologies. The new technologies we worked on today were react-redux and reselect so it took a lot of time to get started. But now we have got started and i expect the process will speed up. 4
EBS
13/05/2018 15:43
We did not follow the process very strictly and i ended up doing a bunch since i couldnt keep focus on technology i did not understand 5
EBS
23/04/2018 12:32
We worked half the day on one large error which was due to just one small word that had to be added to a line of code. This drained morale but at the same time once it was solved everyone was extra happy.
Internals\\Daily retrospectives No
0.0313
3 1
EBS
11/05/2018 21:46
What needs improvement? We need to improve how we explain what we’re thinking. The driver needs to understand what you wish to do. Can be improved by: Explain the end goal, the context and concept of what we are going to do, before stating code.
Reports\\Coding Summary By Node Report
Page 27 of 62
APPENDIX C. THEMES FROM ANALYSIS
73 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
2
EBS
11/05/2018 21:48
One thing that was good that we should keep doing Keep trying to get better at navigating. Be aware of what you’re saying, referring to line numbers, explain concepts. 3
EBS
13/05/2018 15:43
1
EBS
13/05/2018 15:43
We learned more about sql
Internals\\Elias Sørensen Diary No
0.1705
6
At times however, as driver, I felt that the navigators maybe took a bit too much detailed control. This happened because I had a way I usually generated code, but they were used to another. After learning my teammates’ way however, that specific conflict might not happen again. I learned something new about the java editor, but the flow broke. Other than that, I was motivated by the fact that the whole team googled and discussed the errors. When facing such errors on my own, a googling session could take a lot longer time. 2
EBS
13/05/2018 15:43
During the day we encountered a few problems building the project. Initially, the problems were related to data types, and after those were fixed, we had trouble with file paths. By changing the build setup, and spending some time googling, the team found a solution. 3
EBS
23/04/2018 12:50
Today was a good day of mob programming. As something I mostly experience when developing, we had some encounters with code failures we didn’t quite understand. However, we were able to stay bright, and took breaks when we had struggled for a long time. Work went well today, and we had fun programming together. The spirit was high during the whole session. We were more self aware, and took into consideration what we had from yesterday’s retrospective 4
EBS
13/05/2018 12:53
5
EBS
13/05/2018 12:53
2018-02-21
We made the setup for front-end, and even made a map in browser! We solved the problems together with different solutions, and mistakes were continuously corrected as we coded. When we got stuck, we fixed it swiftly for the most part. The last problem, we were unable to fix today, but we were able to identify where the problem is caused, and now only need to find out how to fix it 6
EBS
13/05/2018 15:43
We encountered a few challenges with data structures and redux, but work went swiftly for the most part
Internals\\Ole Kristian Aune Diary No
0.1803
5 1
EBS
13/05/2018 15:43
Today we implemented the docker configuration for testing the server/api. It went fairly smooth compared to the other days struggling with learning docker. I feel that we are now figuring out how it works. 2
EBS
13/05/2018 15:43
The main struggle today was finding out which version of junit to use for testing with springboot since it’s our first time using the framework. In the end we managed to get them running on version 4 and it feels good ending the day with all code running. 3
EBS
13/05/2018 15:43
Today was a bit less productive than yesterday. We tried fixing some problems with our continuous integration setup. Made frontend tests actually fail when a test fails and started speeding up backend testing. Reports\\Coding Summary By Node Report
Page 28 of 62
APPENDIX C. THEMES FROM ANALYSIS
74 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
4
EBS
13/05/2018 15:43
Started day with working docker configuration. We wanted to speed up the testing time with CI, and started figuring out what we could cache for speedier integration tests. We managed to get it working locally, but ended day with error on travis. A bit of a confusing and hard day, but we managed to stay motivated most of the time 5
EBS
12/05/2018 09:19
At times there was some frustration and negative vibes, but we pulled through and got a lot done. We still need to get better at communication / explaining what we mean, and be patient when explaining to others
Internals\\Video transcriptions No
0.4972
23 1
EBS
13/05/2018 15:43
At video 0123, 23:23 Teamwork interaction Ole: Oh, I think we want to name that Ole: Elias, could you figure out how to name a container with docker-compose? Elias(starts looking up): Yes Ole(Typing): No, I think we could do this here, we’ll just try one thing. See if you can figure out in the meantime. 2
EBS
13/05/2018 15:43
Ole: We continue where we left off right? Elias: Yes Ole: So, then we can start Elias: Where did we finish before? Ole: We left off on continuous integration with docker and such Elias: Yes, and then we had a commit where there was an error message. Ole: Yes, so I’ll start the timer Elias: Yes, then could you find the error message, so we can google it? Ole: Yes well... ...I know where we start Christian: Then you shouldn’t be the driver Ole: No, but I guess I just have to explain a bit to you Christian: ...No...you shouldn’t drive. Elias, do you want to drive? Elias: I could very well drive Ole: Okay, you won’t get to write so much right away, because there’s some stuff I must go through. 3
EBS
10/05/2018 11:31
Video70124 2018-02-05 10:40 ( The timer beeps for switch while the team discusses folder and package structure, and Elias and Ole switch places. The switch seems to break the work flow. Elias becomes the new driver) Ole: Who is it? Christian: But we need the package first, it’s you Elias Elias: It’s me? Okay. Elias: Then we continue where we left off. Now it’s no longer me who decides what happens Christian: You can still participate in the decision making Elias: Yeah, I’ll come with input and discussion, but uh. Christian: We must have a “data” folder? Elias: But that doesn’t need to lay under “rest”. Christian: It’s not under “rest” now, it’s made under Elias: Data? Ole: What is data? Elias: Data-classes. It’s models. You could say it’s the data representation in the language of.. Christian: You could make a mock folder instead of data, because we technically don’t make data classes now. Or do we make data classes, only that we have a mock object in the data classes? *Keep discussing name conventions from REST documentation*
Reports\\Coding Summary By Node Report
Page 29 of 62
APPENDIX C. THEMES FROM ANALYSIS
75 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
4
EBS
10/05/2018 11:38
16:11(Elias is driving) 2018-02-05 Elias: Should we make members first, or should we make parameters first? Christian: We could make members Ole: We can find out what we need. Christian: I think with members, it’s the same thing really. Christian: String “name”... Christian: That doesn’t make sense Elias(With a confused look): Type? Christian: Type, maybe Elias (asks Ole): Or does it make sense to have an Enum for type? Ole: Uuuhm.. yeah maybe Elias: Enum, i think enum could be smooth Christian(interrupts): Noo, the enum will be so damn large, there are hundreds of objects. Ole: And besides Elias: We must have a register for types somewhere, with string we could compare it directly to Ole: Hmm… Ole: What is it we want “roadobject” to be? Elias: We have defined some stuff in the uuh… issue, haven’t we? (A few second pause) Ole: I am trying to ask the question now; what is it “roadobject” should do? Elias: Roadobject should fetch data from the database, cache that, and then we could retrieve what we need. Christian: What we have defined on beforehand is type and area, hence position, basically. That is the most basic of a roadobject Elias(types): Should we go for this then? Elias: But area, what was that, that would then be a...? Christian: A position, then. Christian. But how do we define a position? Elias: It could be a list, or we could make an own class for position, with “get lat” and “get long” or whatever. Ole: I actually think that a class for that is nice. Christian: I support that Elias: Should we just make it then? 5
EBS
10/05/2018 11:39
19:53(Elias is driving) 2018-02-05 As mentioned in Elias’ diary, he learned something about the IDE that the others were used to do. Elias: Let’s see… code, generate, uhh getter Ole: You’ll want both Christian: You’ll want both Elias: Oops Christian: Cancel, and the you take both. Elias. Getter and set.. yeah, because I can choose both. Code, generate Christian: Getter and setter Elias(tries again) Christian and Ole: laughing Christian: Ah, darn it! Elias: So.. I thought I could select more things Ole: Code, generate, getter and setter Elias(tries a third time): Getter and setter! Elias: I thought you wanted me to select both items from the menu.
Reports\\Coding Summary By Node Report
Page 30 of 62
APPENDIX C. THEMES FROM ANALYSIS
76 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
6
EBS
13/05/2018 15:43
22:54 (Ole is back from being ill, Christian and Elias have been pair programming a couple of days) Elias: We branched out from the report...ap.. uuh branch I think. Ole: But why did you do that? Elias: I don’t remember why we did it, but i believe there was a good reason Christian: Was it that the newest updated Elias: I think we had.. Ole: Yeah, but you don’t want to, if you’ve done stuff i one function, you don’t want it in the branch of another function Elias: No you don’t want that. But there was, I think there was Ole: You’ll want to branch out from master when you make a new feature Elias. But I think there was a reason. Christian: I think there was something that wasn’t done, so it wasn’t ready to merge into master. Ole: Yeah, but then you still don’t want to do that Elias(agrees): You still don’t want take it further. Elias: I don’t remember the reason, but there was something we did that made us want that. Christian: Yeah there was a reason. Ole: You want to have it completely separated. Elias: There was something, some kind of dependency we didn’t want… Ole: If, if there’s something that you’ve updated that you want in the new branch, then you make a pull request for only that function, merge it into master, and make a new branch from master. New functions should always go out from master. Elias: Yeah, so that report stuff shouldn’t have been in this branch at all Ole: No, it shouldn’t have been here. Because it doesn’t belong to this branch at all Elias: Yeah, it’s not related to “get roadobjects”. Christian: It could also be that we forgot it. Elias: Yeah we could’ve forgotten it for all I know. Elias: The question now is what we do with it then Ole: We’ll just let it be like this now. We’ll just don’t do it.. Elias: ...in the future, yes. 7
EBS
10/05/2018 11:47
Video10129 2018-02-15 00:00 (The team are unable to fix their issue because of a function unknown to them within the dependency they use, NVDB) Elias: Should we keep working on this feature so it doesn’t fail any longer, for the first? Christian: But how should we.. Ole: But we cannot do that. Christian: If we don’t know what fails.. Ole: We need to wait for info about that Elias: But… Christian: It was really this that mob programming was supposed to solve..that there isn’t any waiting for stuff Elias: But sometimes you need information from another place than internally within the team. It’s always like that Ole: Yeah, that’s why you often have everyone that’s needed Elias: Yes, in a sprint Christian: The customer should have been here Ole: He should’ve just been sitting here Elias: He is an expert on the api 8
EBS
10/05/2018 11:49
Video 20129 2018-02-15 06:35: (Discussion about defining GET, which is known as standard method) Ole: It’s standard everywhere. It’s the reason why fetch in javascript, if you don’t define anything, is a get-request. Elias: Mm Elias: I still like that it’s explicitly GET, and POST and PUT 9
EBS
10/05/2018 11:51
Video50129 2018-02-15 03:10: (The team laughs because Christian types something weird on the Windows keyboard that has been wrongly mapped from the Mac. ) Mention from Ole (referring to the Mac keyboard): It might have been faster for you to learn that keyboard.
Reports\\Coding Summary By Node Report
Page 31 of 62
APPENDIX C. THEMES FROM ANALYSIS
77 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
10
EBS
10/05/2018 11:54
11
EBS
12/05/2018 09:52
12
EBS
10/05/2018 12:02
2018-02-21 Video 20135 06:32 (Ole talks about CTA, Elias doesn’t know the abbreviation) Elias: C… CTA? Ole: Call To Action Elias: Call To Action
Ole: And then.. Naah not quite, you need Elias: Self-closing Ole: Yes, so a slash, and then close. Elias: And it’s normal to have a space after… before the slash. Ole: Yes, that’s normal convention Christian(finishes typing): Like that
22:45 (Making a Component in frontend, Christian is driver) Ole: You can write aside, and then option-e Elias: Okay, because then Christian, you automatically get a short.. quick key.. I don’t know what I’m trying to say. Christian: What are you talking about? Ole: If you try to.. Elias: Instead of writing all the tag stuff Ole: Div, for example Christian: (types something incorrectly) Elias: Without that Ole: No, without that. No not like that. If you write div, and then option e Ole (confused): What, I was quite sure that would work Ole: Write dot uuuh…. hello, or something like that. And then option e Christian: Option e? Elias: Ole, are you sure that.. Ole(interrupts): Option shift e, is that possible? Hmm no. Elias: Ole, are you sure that not..when I edit in Atom, i just hit enter when I’ve gotten up “div”. Ole: Yeah, but you can’t.. you can’t do it in here. Because this is not... Elias: Not usual uuh.. html? Ole: No, it’s it’s uhm….what’s it called? JSX. 13
EBS
10/05/2018 12:04
25:31 (Christian is still driver) Christian: We put this in “App” didn’t we? No, I don’t remember Elias: No I don’t think we did that Christian: No, then let’s do that Elias: Import menu Christian (types the norwegian word for menu): “Meny” Elias: “Meny”, *then laughing* Ole: That would have worked that too, though Christian: I don’t think so Ole: Yes Elias: Because you must call, Elias(refers to a code line): here you define what you call it
Reports\\Coding Summary By Node Report
Page 32 of 62
APPENDIX C. THEMES FROM ANALYSIS
78 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
14
EBS
13/05/2018 13:42
Ole: This dot props dot children Christian: What is it we’re doing now, could you explain it? Ole: Yes. What we do now is that we make a component that is a wrapper component. So actually all we want from this is that all we put extend from view from now on, Christian: will be added into that section? Ole: Yes, will be added, because all that will be children, so, to the view component. Christian: mhm Ole: So the only advantage we get from this is that we can add a styling, a css in here that specifically styles classname “view”, so all views have a base styling. Video 90135 2018-02-21 15:33 (Elias is the driver) Elias (showing a code line) : Is it better to have it like this? Or not Ole: In that case make it consistent, because it’s not that way above Christian: Just don’t do it instead Ole: No, don’t do it, because that’s often known as a deconstructing way to write it. If you deconstruct an object you have spaces between the edges, while if you make it you don’t. 15
EBS
13/05/2018 15:43
Elias: What if we work a little bit more with this, and if we’re stuck, then we make the wiki, and then come back to it. Ole: mhm Christian: Until half past. It’s not much but... Elias: Let’s try 8 minutes more to wrestle with this, and if it won’t work we’ll take a break from this and work with something else. Ole(proceeds with the problem at hand): Let’s test something.. 16
EBS
10/05/2018 13:09
17
EBS
13/05/2018 15:43
Video40143 17:40 (The team has set up database running in docker) Ole: Now its supposed to work. So if i refresh... Elias: Aah (claps and highfives Ole) Elias: So now we can... Christian: (Stops what he is doing) Did it work? Elias: ...do stuff Ole: Look, we can terminate here. Stopping bachelor server. Look now Ole: Docker compose up build server (Talks about a command he runs) Elias: (claps again) Ole: There it runs... With database (waving finger for emphasis) Christian: Wonderful
2018-04-03 Video 0145_1: 17:20 (Elias got a weird text selector instead of standard by accidentially typing a keyboard shortcut) Only Ole is used to programming on a mac Ole: I dont know what you are doing right now. Christian: (Laughs lightly) Elias: What is this... I dont understand Ole: I dont understand what you are doing either Elias: (Enables a weird mac setting and is unable to get rid of it) All: Laugh Elias: What is this Ole (laughing)
Reports\\Coding Summary By Node Report
Page 33 of 62
APPENDIX C. THEMES FROM ANALYSIS
79 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
18
EBS
10/05/2018 13:13
2018-04-24 Mob programming late in the process. Video 0168_1 05:12 (Implementing a new flow in the submit part of application. Christian is driver) Christian: But what is the goal of this? Elias: The goal is that we… Ole: Confirmation dialog Elias: That we add stuff into the state, and when we press “create case”, then we can fetch that data from the state and add it Christian: So should it pop up a window “create case” with reports “blablabla”, text “blablabla” and then, confirm? Or cancel? Elias: No...more like Ole and Elias in unison: You have done it. Christian(silent, thinking) Elias: You have done it, this is the case that was made, and then you can see the case in a table. See details of the case, or make a new one. That you have a few choices and get navigated. Christian: I can imagine a confirmation dialog when you make the case. Elias: Are you sure you want to make that? Christian: Yes Elias (spells out imagined text in UI): This is the case you are now creating? Ole: mhm Elias(pauses, thinking): It is possible. But it’ll be an extra navigation too. If it’s easy to change stuff, then it’ll maybe be just as well Ole: It’s just that we change what is called where. So if you make it there you add it to the state. Elias and Christian: mhm Elias: And then you get up a dialog with confirm, or “Ok” has the “submit” Ole: Mhm, because, right, if you press “add to case”, then the reports are added to case. So the only thing “Create Case” must do is, the button, is to add the text, and maybe user info if you’re logged in, into the state. Elias: And, and that is maybe natur… Ole(keeps explaining, interrupts): and that is accessed in the dialog, and then you confirm, and then everything is sent in. Elias: I think that’s actually more natural, because the you “build” the case so that it’s like Elias(gesticulates to the current UI element): Here you have the raw data, and we build a case like it’s supposed to look like. That could be natural to do Ole: It could get done 19
EBS
12/05/2018 09:53
Christian: Then we could actually had the text in the window, or would that be weird? Elias: I don’t quite understand what you mean by that Ole: But that will be shown when you take the.. Elias(interrupts): mhm, then it will be shown like a text, then it won’t be shown like an input box, then it will be shown like a text. So that, if you now. What we’re thinking now is that “create case” does not call directly on “submit”, that’s what the dialog should do instead. So “Create Case” is just supposed to add Elias(gesticulating with hand): the items we have into the state in “Current Case” Ole: Yes, the only thing we actually add right now is the text. Elias: mhm Ole: Because the case is already added. Elias: Yes, it will be added when you press those buttons. But what we can start with is that we can make an action that’s called “add text”... “to case”? (pauses) Elias: And then we can receive that action in the “reducer” after. Elias(explains and navigates Christian): So if you go into actions dot js, that’s in the panel here, then you can make a new one that’s called. Christian(starts working) Elias: You can copy that one, yes. (A few seconds pause while Christian is writing) Ole: I don’t like that it lies right there..
Reports\\Coding Summary By Node Report
Page 34 of 62
APPENDIX C. THEMES FROM ANALYSIS
80 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
20
EBS
10/05/2018 13:19
Video 0169_1 2018-04-24 06:02 (Ole is the driver. The team has trouble with search fields in a table) Elias: Huh? What happens if you search on date updated, then? Ole(types on keyboard, searches) Elias(chuckles) Christian: What’s up Elias: Nah, the search is weird Christian: Agree Elias: Is there any, is there any lacking.. I think I know where the error might be. Ole: Okay? Elias: I think it could be lacking consistency between the number of searchable items, and the number of columns. Because we’ve copied this table from an entirely different place. So it could be that that’s why...because what it seems like now is that, maybe the reason why it’s undefined is because there isn’t any column that consists.. Christian: Right. But which “View” are you in now? Elias and Ole: Cases Christian: Okay, that makes sense. Because I believe the react table searches for reports, not cases. Elias(slightly doubtful): Yeah… (Few seconds pause) (At this point Christian turns to his computer) 21
EBS
10/05/2018 13:20
Elias(reads code out loud): Filter dot ID. Filter dot value. So that’s the way we searched in the report table. But it’s probably not similar here. Elias: Could you check what it’s like in the report table? I just want to understand how we’ve implemented it Ole(shows in code): Here’s an own filter method for this one. Elias: Yeah Ole: For date Elias: mhm Ole: We might have to have that here too Elias: So we must Ole: Was it this? Yes. (clicks) Ole: We don’t have it on both.. Elias: That could… fuck things up. Have it on both. Sort-method and filter-method Ole: Why is this indented so strangely? Elias: try. Try-catch Ole(clicks): I’m just trying to figure out… (A few seconds pause while Ole is typing) Elias: What are you doing? Ole: It worked Elias: Now you found cases. Ole(typing) Elias: I don’t understand. What happens if you type in the user field? Write four there. Ole(types as instructed) Elias(reacts to result): Ho-how! That’s pretty fucked up. Elias: All of them are “filterable”. Uhm...shouldn’t maybe...shouldn’t we have an own filter-method on each column? (They keep trying to solve the problem) 22
EBS
10/05/2018 13:51
21:13 ( The team continues, Elias is now driver. . Ole sits in the low armchair in the corner instead of by one of the navigator computers.) Ole: I’ll sit here. Contribute a bit from here. Elias: I suggest.. Ole(stands up and fetches his glasses from the table. : Mhm? Elias: That we make an own filter-method on this. Or at least fix to accessor is right, because.. Ole(Sits down again): Yes, go ahead! Elias(shows something on screen): Here.. no.. not here, Elias(goes somewhere else): Here! Ole: I think that “to lower case” isn’t valid on a number Elias: Yes, but that’s because we can’t use standard filter method, we must make on of its own. Ole: Yes, make a own filter method there Elias(shows code on screen): Yes, because here we’ve got that. Elias: Accessor, that.. Here we compare with the string I think actually, and not with uhh.. Ole: But there the type is a string Elias(waves finger for emphasis): That’s the reason! Ole: That is a string.
Reports\\Coding Summary By Node Report
Page 35 of 62
APPENDIX C. THEMES FROM ANALYSIS
81 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
23
EBS
10/05/2018 13:56
Video 10169_1 2018-04-24 01:30 Elias: A number can’t contain another number. The thing is that we must convert them to strings. We musk make sure the numbers are strings. Couldn’t we say.. how Ole: I’ll look it up. Elias: I have a way meanwhile. A quick-fix. Elias(refers to what he’s typing on screen): You take that plus that Elias(laughs): Ole(glances at the screen): No Elias(smiling): This is a hack. Just to check that the.. Christian: I don’t think that will work Elias(keeps typing): Why won’t it work? It is a string now. Christian(laughing): This is fricking hacky Elias(typing and running the result): He-he-heyyyy Christian and Elias (laughing) Ole(shakes his head) Elias: The problem is that we’re searching with number equals number. If we don’t have any static types in javascript, we just have to hack around a string. Elias(keeps laughing) Christian: Well yes Elias: This worked Christian: It worked pretty well, too. Elias(laughing some more and takes a sip of coffee) Ole(keeps searching) Christian: It was fast too Elias: This was fast, Ole. Elias(jokingly): This is like it’s meant to be Ole(refers to the source in which he’s reading): The worst is that some people here say “take the number, and add an empty string”. (Everyone laughing) Elias: Which is what I did. Christian: The hack is the way to go? Elias: Yes, but that is because. Had it been another programming language which had static types, had it been Typescript Christian: Then you could have converted it to a string. But here you just have to say that Ole(interrupts): Ehm. Elias, Elias, Elias, Elias. You know what we’ll do? Which is just a significantly more pretty way to do it. Don’t write that string and a plus, but take… Ole(gestures towards screen): if you remove that.. Elias: Could you tell me what you’re planning to do? Ole: Yes, just take dot to-string. Elias. Could I do that here? Ole: Yes
Nodes\\Motivation Document Internals\\2018-02-20_ Sprint retrospective No
0.0390
1 1
EBS
17/04/2018 15:01
We have been good at motivating each other when working on tough tasks.
Reports\\Coding Summary By Node Report
Page 36 of 62
APPENDIX C. THEMES FROM ANALYSIS
82 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
13/05/2018 12:08
Internals\\Christian Echtermeyer Diary No
0.2148
8
Our work didn't start before around 12:30 due to working on another project (CCD) and therefore we decided to work untill 18:00. I am very exhausted after todays work, maybe because it is monday, maybe because we worked late just setting things up which i am not a fan of. I feel the team worked well today and we got work done, although my mood was declining towards the end and did not match my fellow teammates. 2
EBS
17/04/2018 15:21
I think the project is moving along nicely now and i think we will be able to present something decent at the first sprinte review, although time might be a limitation considering it will get busy with the other courses towards the end of the sprint. 3
EBS
23/04/2018 11:15
Todays work got done quickly and efficiently and we have a good amount of breaks inwhich we played billiard. Due to this i dont feel too exhausted and have a positive view on tomorrow. 4
EBS
13/05/2018 12:08
I have slight trouble keeping focus when working with set-up since it is really boring when it keeps failing. We didnt really follow the process too tightly either as a whole lot of time was spent simply waiting for builds to pass or fail, or doing research on what might work. I hope we will get things going again tomorrow 5
EBS
23/04/2018 12:17
The process was smooth today and we switched often when programming. I also think the amount and frequency of breaks was good, i think we had around 5 total. My mood was good today and maybe even improved slightly by seeing uss get a lot of work done 6
EBS
23/04/2018 12:25
7
EBS
12/05/2018 09:31
Overall this was a nice and short day and a decent end to the week.
Working on the views is fun and yields immediate results which are good for the mood. We did not hit any huge errors today and since we got started so well we decided to work an hour extra. I felt this day went quite good and the team worked well. 8
EBS
23/04/2018 12:32
We worked half the day on one large error which was due to just one small word that had to be added to a line of code. This drained morale but at the same time once it was solved everyone was extra happy.
Internals\\Daily retrospectives No
0.0101
2 1
EBS
17/04/2018 14:18
2
EBS
17/04/2018 14:25
What went well? Efficiency when working Motivated by progress
Even though someone gives up, someone keeps the spirit up, and don’t give up!!!
Reports\\Coding Summary By Node Report
Page 37 of 62
APPENDIX C. THEMES FROM ANALYSIS
83 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
0.2312
6
Reference Number
Coded By Initials
Modified On
1
EBS
23/04/2018 12:50
Internals\\Elias Sørensen Diary No
Today was a good day of mob programming. As something I mostly experience when developing, we had some encounters with code failures we didn’t quite understand. However, we were able to stay bright, and took breaks when we had struggled for a long time. Work went well today, and we had fun programming together. The spirit was high during the whole session. We were more self aware, and took into consideration what we had from yesterday’s retrospective 2
EBS
14/05/2018 12:40
I think the whole team was kind of slacking today, but since it concerned the whole team, it wasn’t that bad. We didn’t get as far as programming today, so I didn’t feel like we did much useful. On a day like this I felt like I could’ve done lots of other useful things than try to fix those docker problems. 3
EBS
13/05/2018 12:08
Today we worked with setting up an optimized contiuous integration, as the slow build was hindering progress in our work, because everyone has to wait for the build. We had no success in fixing it completely, but had some promising tries. It was demotivating to only work with setup again. I had long periods of time where I really felt I could have been of better use doing other stuff. Other times, the cooperation was productive in finding problems. 4
EBS
23/04/2018 13:03
Navigation went well, and I am also starting to get used to being navigated. I also feel the code quality of the day was nice, and we god more than acceptable naming conventions almost immediately. We are ahead of schedule, which feels really motivating. 5
EBS
23/04/2018 13:05
We made productive, working code, and I noticed that mostly, syntax errors were discovered instantly. Also, we had good naming conventions, and solved most problems that occured, rather swiftly. I got really frustrated with the error we had, but finally solving it was satisfying. 6
EBS
13/05/2018 12:08
2018-03-05 We had demo of second sprint in the beginning of the day. Then we worked on the new admin client. I and Ole were pair programming This was a semi decent day. Demo went well in the beginning of the day, and we learned that we had to take a new direction. I and Ole started working on the new part of our system, the admin part. We were able to swiftly remove some parts from the client we duplicated, but had some problems adding a new dependency. We struggled on that for about an hour, which was demotivating. Other than that, I felt we pair programmed productively, and made mock up table view.
Internals\\Ole Kristian Aune Diary No
0.2893
7 1
EBS
13/05/2018 12:08
Started the day motivated, ended day with a slight headache and a little less motivated due to some unnecessary discussion about working hours 2
EBS
13/05/2018 12:08
Today I started off not in the best mood. I still had some pain in my body hanging around from yesterday. Luckily today was a day filled with progress. We almost finished an entire rest endpoint, which hopefully will make the rest of them easier. The process also worked better today with breaks in between work sessions. I expect that tomorrow will go well and we will get much more progress. 3
EBS
23/04/2018 14:32
We wanted to speed up the testing time with CI, and started figuring out what we could cache for speedier integration tests. We managed to get it working locally, but ended day with error on travis. A bit of a confusing and hard day, but we managed to stay motivated most of the time. Some became a little bit of zombie programming at times today 4
EBS
12/05/2018 09:15
Looking forward to some frontend work the coming days. It’s the part I like the most, and find most rewarding. Hope I feel the same way when mob programming on this task also. Reports\\Coding Summary By Node Report
Page 38 of 62
APPENDIX C. THEMES FROM ANALYSIS
84 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
5
EBS
12/05/2018 09:17
Not a lot of difficulties with anything today, we were stuck on a test for some time, but I think the test is wrong with the new implementation, not the code itself. We have to look into it, but if it doesn’t cause visible problems, I think we are safe to move on for now. Good to finally have some visual feedback. I work best with visual stuff to get a grasp of the task, and knowing we all are on the same page. A good day! 6
EBS
23/04/2018 14:37
Made a lot of progress today, worked some more on frontend and have all basic components in place. Also added some basic styling and changed to use redux state. Lots of progress today as well, so we are still ahead of our goal for the sprint :D 7
EBS
13/05/2018 12:08
At times there was some frustration and negative vibes, but we pulled through and got a lot done. We still need to get better at communication / explaining what we mean, and be patient when explaining to others.
Internals\\Video transcriptions No
0.0499
5 1
EBS
13/05/2018 10:11
2
EBS
10/05/2018 11:53
3
EBS
13/05/2018 12:08
Christian: Heey, it worked Everyone(celebrating, stretching hands into the air) Ole: Test exited with code 0. Christian: That was what we wanted Ole: It sounds very promising. Øystein(nods and gives a thumbs up): That is what we like
Video 90129 2018-02-15 17:00 (Switching driver from Elias to Christian.The test just implemented fails.) Ole: Run the rest. Did we run the other test? Elias: No Ole: Then let’s run that one too. Ole: Okay, it failed Christian: It failed Elias: Boys, should we take a break? Ole: Soon, we’ll just make this one not fail. Christian: Why isn’t this equal? Elias: I think it’s because we must implement equals Ole: In user. Elias: In user Ole: On a user Elias: On a user Elias: Implement equals Ole: Generate
2018-03-15 Pair programing Christian and Ole Video 10148_1 04:40-26:30 Help from Øystein. They came no further solving the problem Video 10149_1: Nothing Video 20147_1: Long break, nothing Video 20148_1: Nothing of interest. Continued help from øystein. No progress The rest of the videos were basically without content to mention This whole day and the day before were based on struggle with Docker and Database. The team didn’t get anywhere.
Reports\\Coding Summary By Node Report
Page 39 of 62
APPENDIX C. THEMES FROM ANALYSIS
85 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
4
EBS
13/05/2018 12:08
5
EBS
10/05/2018 13:09
1
EBS
14/05/2018 13:32
2018-03-22 Video30143 02:10 (Christian is writing report, Ole and Elias are pair programming) Ole (regarding Docker, talking to Christian): You miss this don't you Elias: Run it Ole: Do you miss this (once again talking to Christian) Christian: Hmm? (Looks at screen) Christian: No (smiles)
Video40143 17:40 (The team has set up database running in docker) Ole: Now its supposed to work. So if i refresh... Elias: Aah (claps and highfives Ole) Elias: So now we can... Christian: (Stops what he is doing) Did it work? Elias: ...do stuff Ole: Look, we can terminate here. Stopping bachelor server. Look now Ole: Docker compose up build server (Talks about a command he runs) Elias: (claps again) Ole: There it runs... With database (waving finger for emphasis) Christian: Wonderful
Nodes\\Problem Solving Document Internals\\2018-04-18_Sprint retrospective No
0.1187
1
We took the right choices, but we should have come there sooner. We should find an easier solution instead of being persistent and fight the problem. We don’t ask for help enough when we’re struggling to avoid waste of time.
Internals\\Christian Echtermeyer Diary No
0.2147
6 1
EBS
14/05/2018 13:32
I think tomorrow will be a easier day as we finally get to work on some slightly more interesting things. Generally todays productivity felt alright. We hit a lot of errors, mainly due to setting up the project being new to all of us. 2
EBS
14/05/2018 13:32
Today we worked more or less only on trying to set-up caching for the continuous integration with travis. We had varying degrees of sucess on this front, we managed so set it up for local caching but the CI tests on travis still dont cache properly and it seems to be very tough to fix. 3
EBS
14/05/2018 13:32
A few of our goals were not really reached but were a bit of a stretch to begin with due to the fact that we still had a lot of university work paralell. We got some good advice, specially regarding that it might not be worth the time spent on getting a perfect continuous integration environment and instead focus on getting the program up and running with good functionality. Reports\\Coding Summary By Node Report
Page 40 of 62
APPENDIX C. THEMES FROM ANALYSIS
86 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
4
EBS
14/05/2018 13:32
The new technologies we worked on today were react-redux and reselect so it took a lot of time to get started. But now we have got started and i expect the process will speed up. The team worked well, Elias had to go for a job interview but the rest worked well up to lunch and we got the components we had planed done. We did not follow the process very strictly and i ended up doing a bunch since i couldnt keep focus on technology i did not understand. 5
EBS
14/05/2018 14:11
We started off slow trying to fix an error from the day before, but once we got that fixed things were smooth sailing. towards the end of the day when implementing scss we struck errors again. I feel this is a very normal workflow these days. We get a lot of things done until we hit an error then things stop completely and we leave for the day. Next day we fix the error and repeat. 6
EBS
14/05/2018 14:11
We worked half the day on one large error which was due to just one small word that had to be added to a line of code. This drained morale but at the same time once it was solved everyone was extra happy.
Internals\\Daily retrospectives No
0.0404
5 1
EBS
14/05/2018 14:11
2
EBS
14/05/2018 13:32
3
EBS
14/05/2018 13:32
4
EBS
14/05/2018 13:32
By thinking differently, we were able to efficiently fix the bugs that arose
We need to be more productive than this The docker build-stuff is still bad
Talk to an expert
When in doubt of where to take the project, we asker our tutor At first we had a long discussion of how we should make our admin view, but ended up asking Espen for advice. 5
EBS
14/05/2018 13:32
EBS
14/05/2018 14:11
What went well? We recognised we needed help and therefore finally managed to create a database What needs improvement? Setup is tough and not much can be done about it How can we improve this? Get more help when we are stuck
Internals\\Elias Sørensen Diary No
0.2421
9 1
We added one unit test, which we were troubled with for some time, due to our lacking knowledge of JUnit combined with Spring-Boot. However, the team managed to fix the failing test before the day ended. 2
EBS
14/05/2018 14:11
Other than that, I was motivated by the fact that the whole team googled and discussed the errors. When facing such errors on my own, a googling session could take a lot longer time.
Reports\\Coding Summary By Node Report
Page 41 of 62
APPENDIX C. THEMES FROM ANALYSIS
87 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
3
EBS
14/05/2018 14:11
Today was a good day of mob programming. As something I mostly experience when developing, we had some encounters with code failures we didn’t quite understand. However, we were able to stay bright, and took breaks when we had struggled for a long time 4
EBS
14/05/2018 13:32
We started late because two of the team members had meetings in the morning. Then the team proceeded to fix a problem with travis ci. After lunch, the team tried to fix the slow docker building, without success. 5
EBS
14/05/2018 13:32
2018-02-19 Today we worked with setting up an optimized contiuous integration, as the slow build was hindering progress in our work, because everyone has to wait for the build. We had no success in fixing it completely, but had some promising tries. 6
EBS
14/05/2018 14:11
2018-02-21 Today we worked on setting up the structure on front-end. We made the key components, and added a map view. We had some problems with rendering child components in the test suite, which we were unable to fix. In the end of the day, we made some documentation. I felt we were very efficient today. We made the setup for front-end, and even made a map in browser! We solved the problems together with different solutions, and mistakes were continuously corrected as we coded. When we got stuck, we fixed it swiftly for the most part. The last problem, we were unable to fix today, but we were able to identify where the problem is caused, and now only need to find out how to fix it 7
EBS
14/05/2018 13:40
We started the day by fixing redux problems from last day. After that we implemented the main view, and added components. Then we added scss, which gave us some other setup problems to work with. I felt like I got alot of stuff done today. As we switched drivers, code was written swiftly, and new components added with relative ease. I think we have found a decent timing with 7+3, and it feels like I’m productive. 8
EBS
14/05/2018 14:11
Today was another great day. We spent something like two hours on a small syntax error none of us was able to spot early. Other than that I felt like things were great. 9
EBS
14/05/2018 13:32
We encountered a few challenges with data structures and redux, but work went swiftly for the most part
Internals\\Ole Kristian Aune Diary No
0.2392
5 1
EBS
14/05/2018 13:32
The main struggle today was finding out which version of junit to use for testing with springboot since it’s our first time using the framework. In the end we managed to get them running on version 4 and it feels good ending the day with all code running. 2
EBS
14/05/2018 13:32
Today was a bit less productive than yesterday. We tried fixing some problems with our continuous integration setup. Made frontend tests actually fail when a test fails and started speeding up backend testing. 3
EBS
14/05/2018 14:11
Started day with working docker configuration. We wanted to speed up the testing time with CI, and started figuring out what we could cache for speedier integration tests. We managed to get it working locally, but ended day with error on travis. A bit of a confusing and hard day, but we managed to stay motivated most of the time. Some became a little bit of zombie programming at times today 4
EBS
14/05/2018 13:40
Not a lot of difficulties with anything today, we were stuck on a test for some time, but I think the test is wrong with the new implementation, not the code itself. We have to look into it, but if it doesn’t cause visible problems, I think we are safe to move on for now. Good to finally have some visual feedback. I work best with visual stuff to get a grasp of the task, and knowing we all are on the same page. A good day!
Reports\\Coding Summary By Node Report
Page 42 of 62
APPENDIX C. THEMES FROM ANALYSIS
88 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
5
EBS
14/05/2018 14:11
We had some struggles with a bug on the first task of the day, resulting in not getting past the first task before lunchtime. However, right after lunch we figured it out and managed to finish all tasks for the day (except own study). I felt a lot of progress today as well despite wasting half a day on one small problem.
Internals\\Video transcriptions No
0.2497
14 1
EBS
14/05/2018 13:32
At video 010122, 18:50 First knowledge issues with docker, asking for help outside the team suggested 2
EBS
14/05/2018 14:11
Ole: It’s just that we’ve set it up wrong. The first thing was that when we ran it here, you see that it sets stuff up and runds the tests. Then it says the tests pass. Elias: Now there’s watching on the tests Ole: ... So it says there was no output recieved. So we just terminate because it times out Elias: That was exciting Øystein(reads log): Yes, cuz there’s nothing that says.. exit 0. This is awesome. Right Ole: So we don’t quite know how we... Øystein: But how do the tests run. What command runs the tests? Ole: It was the one we had when... Elias: We used docker compose compose... Ole: Services docker, docker compose up build and we’ve set up a “client test” Elias: And that was because we made an image for the test stuff, and made an own docker file. Dockerfile dot test...It depents how that really works.. Ole: We were running yarn test actually.. 3
EBS
14/05/2018 13:32
23:28 (Approx. 20 Minutes starting session with help Øystein. Elias and Øystein are currently casuallt chatting while Ole is the driver, trying a new solution) Ole: So if we now try... Elias: I suppose “drifters” maybe have a bit more of such shellscript programming Ole(typing): We must run it again.. Øystein: Well, the whole thing where you make tooling and such things. It is...the developer should be able to make tooling, make deploy tooling and such things. And then you have to do programming with shell script Elias: Yes, to do it as easy as possible to work Øystein: To make it possible Elias(laughs): To make it possible Christian: Heey, it worked Everyone(celebrating, stretching hands into the air) Ole: Test exited with code 0. Christian: That was what we wanted Ole: It sounds very promising. Øystein(nods and gives a thumbs up): That is what we like
Reports\\Coding Summary By Node Report
Page 43 of 62
APPENDIX C. THEMES FROM ANALYSIS
89 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
4
EBS
14/05/2018 13:32
Video10129 2018-02-15 00:00 (The team are unable to fix their issue because of a function unknown to them within the dependency they use, NVDB) Elias: Should we keep working on this feature so it doesn’t fail any longer, for the first? Christian: But how should we.. Ole: But we cannot do that. Christian: If we don’t know what fails.. Ole: We need to wait for info about that Elias: But… Christian: It was really this that mob programming was supposed to solve..that there isn’t any waiting for stuff Elias: But sometimes you need information from another place than internally within the team. It’s always like that Ole: Yeah, that’s why you often have everyone that’s needed Elias: Yes, in a sprint Christian: The customer should have been here Ole: He should’ve just been sitting here Elias: He is an expert on the api 5
EBS
14/05/2018 13:32
22:45 (Making a Component in frontend, Christian is driver) Ole: You can write aside, and then option-e Elias: Okay, because then Christian, you automatically get a short.. quick key.. I don’t know what I’m trying to say. Christian: What are you talking about? Ole: If you try to.. Elias: Instead of writing all the tag stuff Ole: Div, for example Christian: (types something incorrectly) Elias: Without that Ole: No, without that. No not like that. If you write div, and then option e Ole (confused): What, I was quite sure that would work Ole: Write dot uuuh…. hello, or something like that. And then option e Christian: Option e? Elias: Ole, are you sure that.. Ole(interrupts): Option shift e, is that possible? Hmm no. Elias: Ole, are you sure that not..when I edit in Atom, i just hit enter when I’ve gotten up “div”. Ole: Yeah, but you can’t.. you can’t do it in here. Because this is not... Elias: Not usual uuh.. html? Ole: No, it’s it’s uhm….what’s it called? JSX. 6
EBS
13/05/2018 13:44
Elias: What if we work a little bit more with this, and if we’re stuck, then we make the wiki, and then come back to it. Ole: mhm Christian: Until half past. It’s not much but... Elias: Let’s try 8 minutes more to wrestle with this, and if it won’t work we’ll take a break from this and work with something else. Ole(proceeds with the problem at hand): Let’s test something.. 7
EBS
14/05/2018 13:32
2018-03-15 Pair programing Christian and Ole Video 10148_1 04:40-26:30 Help from Øystein. They came no further solving the problem Video 10149_1: Nothing Video 20147_1: Long break, nothing Video 20148_1: Nothing of interest. Continued help from øystein. No progress The rest of the videos were basically without content to mention This whole day and the day before were based on struggle with Docker and Database. The team didn’t get anywhere.
Reports\\Coding Summary By Node Report
Page 44 of 62
APPENDIX C. THEMES FROM ANALYSIS
90 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
8
EBS
14/05/2018 13:32
2018-04-03 Video 0145_1: 17:20 (Elias got a weird text selector instead of standard by accidentially typing a keyboard shortcut) Only Ole is used to programming on a mac Ole: I dont know what you are doing right now. Christian: (Laughs lightly) Elias: What is this... I dont understand Ole: I dont understand what you are doing either Elias: (Enables a weird mac setting and is unable to get rid of it) All: Laugh Elias: What is this Ole (laughing) 9
EBS
14/05/2018 14:11
(Ole is the driver. The team has trouble with search fields in a table) Elias: Huh? What happens if you search on date updated, then? Ole(types on keyboard, searches) Elias(chuckles) Christian: What’s up Elias: Nah, the search is weird Christian: Agree Elias: Is there any, is there any lacking.. I think I know where the error might be. Ole: Okay? Elias: I think it could be lacking consistency between the number of searchable items, and the number of columns. Because we’ve copied this table from an entirely different place. So it could be that that’s why...because what it seems like now is that, maybe the reason why it’s undefined is because there isn’t any column that consists.. Christian: Right. But which “View” are you in now? Elias and Ole: Cases Christian: Okay, that makes sense. Because I believe the react table searches for reports, not cases. Elias(slightly doubtful): Yeah… (Few seconds pause) (At this point Christian turns to his computer) Elias(reads code out loud): Filter dot ID. Filter dot value. So that’s the way we searched in the report table. But it’s probably not similar here. Elias: Could you check what it’s like in the report table? I just want to understand how we’ve implemented it Ole(shows in code): Here’s an own filter method for this one. Elias: Yeah Ole: For date Elias: mhm Ole: We might have to have that here too Elias: So we must Ole: Was it this? Yes. (clicks) Ole: We don’t have it on both.. 10
EBS
14/05/2018 14:11
13:02 (Christian starts paying attention again, and joins the discussion) Christian: Let me see Elias: On fetch data Christian: That one’s a bit brutal. (Pause) Christian: Can’t you just filter the state instead of “getting” every time? Ole(types something): I must just see what happens if we do like this Elias: Then we get no data? Christian: Huh Ole: What does it do, that on fetch…(types the rest) (Around half a minute silence, everyone checks their phones, do their own thing) (Elias leaves the room while silence continues. Ole seems to do some searching)
16:20 (Ole is still the driver) Ole(after some googling): It says here that it’s recommended to use selectors, and not the state directly Elias: I absolutely believe that Reports\\Coding Summary By Node Report
Page 45 of 62
APPENDIX C. THEMES FROM ANALYSIS
91 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
11
EBS
14/05/2018 14:11
21:13 ( The team continues, Elias is now driver. . Ole sits in the low armchair in the corner instead of by one of the navigator computers.) Ole: I’ll sit here. Contribute a bit from here. Elias: I suggest.. Ole(stands up and fetches his glasses from the table. : Mhm? Elias: That we make an own filter-method on this. Or at least fix to accessor is right, because.. Ole(Sits down again): Yes, go ahead! Elias(shows something on screen): Here.. no.. not here, Elias(goes somewhere else): Here! Ole: I think that “to lower case” isn’t valid on a number Elias: Yes, but that’s because we can’t use standard filter method, we must make on of its own. Ole: Yes, make a own filter method there Elias(shows code on screen): Yes, because here we’ve got that. Elias: Accessor, that.. Here we compare with the string I think actually, and not with uhh.. Ole: But there the type is a string Elias(waves finger for emphasis): That’s the reason! Ole: That is a string. 12
EBS
14/05/2018 14:11
Elias: A number can’t contain another number. The thing is that we must convert them to strings. We musk make sure the numbers are strings. Couldn’t we say.. how Ole: I’ll look it up. Elias: I have a way meanwhile. A quick-fix. Elias(refers to what he’s typing on screen): You take that plus that Elias(laughs): Ole(glances at the screen): No Elias(smiling): This is a hack. Just to check that the.. Christian: I don’t think that will work Elias(keeps typing): Why won’t it work? It is a string now. Christian(laughing): This is fricking hacky Elias(typing and running the result): He-he-heyyyy Christian and Elias (laughing) Ole(shakes his head) 13
EBS
14/05/2018 13:43
Elias: The problem is that we’re searching with number equals number. If we don’t have any static types in javascript, we just have to hack around a string. Elias(keeps laughing) Christian: Well yes Elias: This worked Christian: It worked pretty well, too. Elias(laughing some more and takes a sip of coffee)
Reports\\Coding Summary By Node Report
Page 46 of 62
APPENDIX C. THEMES FROM ANALYSIS
92 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
14
EBS
14/05/2018 13:43
Ole(keeps searching) Christian: It was fast too Elias: This was fast, Ole. Elias(jokingly): This is like it’s meant to be Ole(refers to the source in which he’s reading): The worst is that some people here say “take the number, and add an empty string”. (Everyone laughing) Elias: Which is what I did. Christian: The hack is the way to go? Elias: Yes, but that is because. Had it been another programming language which had static types, had it been Typescript Christian: Then you could have converted it to a string. But here you just have to say that Ole(interrupts): Ehm. Elias, Elias, Elias, Elias. You know what we’ll do? Which is just a significantly more pretty way to do it. Don’t write that string and a plus, but take… Ole(gestures towards screen): if you remove that.. Elias: Could you tell me what you’re planning to do? Ole: Yes, just take dot to-string. Elias. Could I do that here? Ole: Yes
Nodes\\Productivity Document Internals\\2018-02-20_ Sprint retrospective No
0.1021
2 1
EBS
12/05/2018 11:21
2
EBS
17/04/2018 14:59
We were able to solve a lot of difficult problems swiftly
1. Wrong focus in task priorities. We were sitting with travis and such problems too much, instead of giving that one up at time.
Internals\\2018-03-06_Sprint retrospective No
0.1198
2 1
EBS
17/04/2018 15:08
2
EBS
17/04/2018 15:09
We were very productive and got things done.
We have a flow with the timer that works well for uss. We use it more as a guideline, but fairly actively when we are actually writing code, and less actively when researching and testing.
Reports\\Coding Summary By Node Report
Page 47 of 62
APPENDIX C. THEMES FROM ANALYSIS
93 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
17/04/2018 15:12
2
EBS
17/04/2018 15:12
Internals\\2018-03-20_Sprint retrospective No
0.3573
2
We got lots of stuff done in a short time
When we are 3 developers, as opposed to pair, we experience that two of us are “pair programming” while the third person has a break or looks for the next task. It seems like progress is slower as the third man has to catch up to the work the other two are doing.
Internals\\2018-04-18_Sprint retrospective No
0.0772
1 1
EBS
10/05/2018 20:49
2018-04-18: Sprint retrospective What went well? We almost managed to reach the goals of the sprint. We were half a day from completing them all
Internals\\Christian Echtermeyer Diary No
0.2711
11 1
EBS
17/04/2018 15:16
I feel the team worked well today and we got work done, although my mood was declining towards the end and did not match my fellow teammates 2
EBS
17/04/2018 15:17
. Generally todays productivity felt alright. We hit a lot of errors, mainly due to setting up the project being new to all of us. 3
EBS
12/05/2018 09:24
I think the project is moving along nicely now and i think we will be able to present something decent at the first sprinte review, although time might be a limitation considering it will get busy with the other courses towards the end of the sprint. 4
EBS
23/04/2018 11:14
Todays work got done quickly and efficiently and we have a good amount of breaks inwhich we played billiard. 5
EBS
23/04/2018 12:16
Today we started working on the front-end part of the system after deciding to do so on the sprint meeting. Things went smoothly and it is nice to see progress physically on the screen instead of on tests. Maybe due to this i felt the team got a lot of work done and we have made a lot of progress 6
EBS
12/05/2018 09:29
Towards the end of the day we had some trouble with the map we made, but we decided after spending time that we wanted to move forward. I think this is a good decision as we didnt get too sick of working on one thing and instead moved onto something else. The process was smooth today and we switched often when programming. I also think the amount and frequency of breaks was good, i think we had around 5 total. 7
EBS
23/04/2018 12:19
The work seemed a lot slower than yesterda simply judging by the progress, but it may have been affected by once again learning new technologies
Reports\\Coding Summary By Node Report
Page 48 of 62
APPENDIX C. THEMES FROM ANALYSIS
94 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
8
EBS
23/04/2018 12:19
The new technologies we worked on today were react-redux and reselect so it took a lot of time to get started. But now we have got started and i expect the process will speed up. 9
EBS
23/04/2018 12:22
11:30 was the official start time of the day, so we started with a good lunch and mood was good. We started off slow trying to fix an error from the day before, but once we got that fixed things were smooth sailing. 10
EBS
12/05/2018 09:31
We started worked on more front-end views and refactoring. Things went smoothly and i felt we got a lot of work done and we are well ahead of schedule on the sprint. Working on the views is fun and yields immediate results which are good for the mood. 11
EBS
23/04/2018 12:33
Once we got it solved things seemed to go very smoothly, even things that at first seemed difficult ran on the first try which is very rare. The mood of the team was a bit mediocre at the beginning but now at the end of the day i myself and i believe the team aswell feel we ended on a high point and are ready for tomorrow
Internals\\Daily retrospectives No
0.0863
18 1
EBS
17/04/2018 14:09
2
EBS
17/04/2018 14:11
3
EBS
17/04/2018 14:13
4
EBS
17/04/2018 14:13
5
EBS
17/04/2018 14:14
The little programming we did today, went well (worked very good, nice flow)
We were efficient
Efficient work. We worked very nicely when we first got started.
Things went swiftly after today’s meeting. We pushed on, and got stuff done
Completing the menu implementation was very nice and efficient, even though the plan was to research 6
EBS
17/04/2018 14:18
7
EBS
17/04/2018 14:18
8
EBS
17/04/2018 14:20
9
EBS
17/04/2018 14:21
Efficiency when working Motivated by progress
Good feeling being ahead of schedule
Change task when using to long on one problem
What went well? We worked efficiently and according to the plan We got the work done thas was on the plan One of the most efficient days, specially the navigation was smooth Reports\\Coding Summary By Node Report
Page 49 of 62
APPENDIX C. THEMES FROM ANALYSIS
95 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
10
EBS
17/04/2018 14:24
11
EBS
17/04/2018 14:26
12
EBS
17/04/2018 14:26
13
EBS
17/04/2018 14:28
14
EBS
12/05/2018 09:50
15
EBS
17/04/2018 14:29
16
EBS
17/04/2018 14:42
When we first solved the error, things went smoothly after lunch
Work was efficient
Made good choices prioritising tasks
We got a lot of work done.
Discussion of naming variables sometimes breaks the flow we’re in
Demo, we had achieved all goals for the sprint Good progress on new part of project (admin)
We got a lot of stuff done, was productive. Based on our choice to use of the library react-table, lots of functionality was easy to implement 17
EBS
17/04/2018 14:43
18
EBS
17/04/2018 14:53
1
EBS
23/04/2018 12:46
We got a lot of work done in a short amount of time
We were efficient and produced decent amounts of features.
Internals\\Elias Sørensen Diary No
0.2997
10
I had mixed experiences of the first day of mob programming. I felt at times that we had progress considering that we right there and then made a decent naming convention, and formatting was immediately set to our preference because we debated how it was supposed to be. At times however, as driver, I felt that the navigators maybe took a bit too much detailed control. 2
EBS
23/04/2018 12:58
It was demotivating to only work with setup again. I had long periods of time where I really felt I could have been of better use doing other stuff. Other times, the cooperation was productive in finding problems. 3
EBS
23/04/2018 12:58
We didn’t really do alot of mob programming today, but the little hour we had before demo, we had to rewrite some things due to a refactoring. Work flowed well in my opinion. I think it’s bad that we didn’t manage to finish the task before the demo, because catching where we left off can be inefficient and difficult. 4
EBS
13/05/2018 10:19
I felt we were very efficient today. We made the setup for front-end, and even made a map in browser! We solved the problems together with different solutions, and mistakes were continuously corrected as we coded. When we got stuck, we fixed it swiftly for the most part. The last problem, we were unable to fix today, but we were able to identify where the problem is caused, and now only need to find out how to fix it Reports\\Coding Summary By Node Report
Page 50 of 62
APPENDIX C. THEMES FROM ANALYSIS
96 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
5
EBS
23/04/2018 13:00
2018-02-22 Today we implemented a menu for front-end, and then added a simple redux structure. Programming went well today. Like the other days this week, I felt kind of tired in the end of the day. I felt programming went well, and we were able to produce decently. I think we were able to navigate well. 6
EBS
23/04/2018 13:01
2018-02-23 We started the day by fixing redux problems from last day. After that we implemented the main view, and added components. Then we added scss, which gave us some other setup problems to work with. I felt like I got alot of stuff done today. As we switched drivers, code was written swiftly, and new components added with relative ease. I think we have found a decent timing with 7+3, and it feels like I’m productive. 7
EBS
23/04/2018 13:02
Today I felt we had one of the most efficient days as of yet. Progress went swiftly, and we merged several components. I also had lots of fun along the way, and lunch seemed to appear suddenly. 8
EBS
23/04/2018 13:05
We made productive, working code, and I noticed that mostly, syntax errors were discovered instantly. Also, we had good naming conventions, and solved most problems that occured, rather swiftly. I got really frustrated with the error we had, but finally solving it was satisfying. 9
EBS
23/04/2018 13:06
I felt like today was an awesome day. Progress is easily noticed on front-end. Driving and navigating also feels better than earlier. We have started stating line numbers when the driver is trying to find where in the code the navigator is looking. That makes it a lot easier to find said code block when I’m the driver 10
EBS
23/04/2018 13:08
I felt today, with mob programming again, was nice. We had decent progress, and didn’t face any major problems. We didn’t use a timer at all today, which felt more relaxing. I felt I, and my teammates were useful
Internals\\Ole Kristian Aune Diary No
0.2642
8 1
EBS
23/04/2018 14:31
Today was a very productive day. We implemented all rest api endpoints for user and added lots of tests. It all went really smooth and collaboration worked really good. No major set backs and lots of progress. All in all very happy with how smooth the system worked today. 2
EBS
23/04/2018 14:33
We had a really good session after lunch, and I feel we are good on track for this sprint although last sprint ended under the goal (it was way too ambitious). Looking forward to some frontend work the coming days. It’s the part I like the most, and find most rewarding. Hope I feel the same way when mob programming on this task also. 3
EBS
23/04/2018 14:34
First real frontend day. Made wireframes, implemented base skeleton on most components and made the map work. Work was smooth and we finished most of our tasks for the day. 4
EBS
23/04/2018 14:36
Made progress with menu and redux store. Unfortunately we didn’t finish the last task, but I think it was a good choice to stop when we did. A little time for self study today was also very good 5
EBS
23/04/2018 14:37
Decided to change from css to scss, but encountered some problems in the process witch we didn’t complete. Good progress for a half day of work.
Reports\\Coding Summary By Node Report
Page 51 of 62
APPENDIX C. THEMES FROM ANALYSIS
97 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
6
EBS
12/05/2018 09:18
26-02-2018 Made a lot of progress today, worked some more on frontend and have all basic components in place. Also added some basic styling and changed to use redux state. Lots of progress today as well, so we are still ahead of our goal for the sprint :D 7
EBS
23/04/2018 14:38
We had some struggles with a bug on the first task of the day, resulting in not getting past the first task before lunchtime. However, right after lunch we figured it out and managed to finish all tasks for the day (except own study). I felt a lot of progress today as well despite wasting half a day on one small problem. 8
EBS
23/04/2018 14:39
1
EBS
13/05/2018 11:18
Lots of progress, and we worked good to get closer to our finished product.
Nodes\\Role Switching Document Internals\\2018-02-20_ Sprint retrospective No
0.2033
2
2. Didn’t always follow the clock 3. We could switch more often when someone has an idea. The driver should not navigate himself. Generally switching driver 2
EBS
17/04/2018 15:00
2. Try to follow the clock as much as possible. Remind each others. Try changing times, especially the switch time, so we are able to wrap up a task 3. Everyone focuses on the task, and everyone should remind each other..
Internals\\2018-03-06_Sprint retrospective No
0.2117
3 1
EBS
17/04/2018 15:09
We have a flow with the timer that works well for uss. We use it more as a guideline, but fairly actively when we are actually writing code, and less actively when researching and testing. 2 Instead of following the timer stricly we can try being more free How could we fix it: Use timer as a guideline but switch mostly when we feel 3
EBS
13/05/2018 12:58
like it. EBS
17/04/2018 15:10
Use timer as a guideline but switch mostly when we feel like it.
Reports\\Coding Summary By Node Report
Page 52 of 62
APPENDIX C. THEMES FROM ANALYSIS
98 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
12/05/2018 12:05
Internals\\2018-03-20_Sprint retrospective No
0.1867
1
Working without a timer worked well, though sometimes maybe we are sitting too long. But it’s better to tell when you want to switch instead of being disturbed
Internals\\2018-04-18_Sprint retrospective No
0.3042
3 1
EBS
12/05/2018 12:04
Working without timers worked well. We switch more rarely, but there’s more natural points to switch, like a completed feature, or when someone needs to catch up. 2
EBS
13/05/2018 13:00
We felt that the roles in pair programming weren’t as distinguishable as in mob. When in pair, there was more a back and forth discussion of the development, while in mob, the driver has more than enough with catching all the commands from the navigators 3
EBS
12/05/2018 12:05
Sometimes we don’t switch often enough, likely because we don’t have a timer. But with a timer we experienced that the timer was an annoyance and broke the flow
Internals\\Christian Echtermeyer Diary No
0.0384
2 1
EBS
12/05/2018 10:05
The process was smooth today and we switched often when programming. I also think the amount and frequency of breaks was good, i think we had around 5 total. My mood was good today and maybe even improved slightly by seeing uss get a lot of work done 2
EBS
12/05/2018 09:32
I felt the team worked well, we more or less ignored the timer but everyone got to write anyway.
Internals\\Daily retrospectives No
0.1126
18 1
EBS
17/04/2018 13:52
2
EBS
17/04/2018 13:54
3
EBS
17/04/2018 14:00
EBS
17/04/2018 14:12
We forgot to start timer
Try auto-timer.
Autotimer worked well, people forgot to put it on but now it seems to work well for us 4 Driver switching went well when programming Reports\\Coding Summary By Node Report
Page 53 of 62
APPENDIX C. THEMES FROM ANALYSIS
99 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
5
EBS
17/04/2018 14:12
6
EBS
17/04/2018 14:12
Driver switching can still be improved slightly
We want to try a different time, see how that works. Possibly shorter times, maybe more small break time aswell 7
EBS
17/04/2018 14:14
8
EBS
17/04/2018 14:17
9
EBS
17/04/2018 14:19
10
EBS
13/05/2018 13:27
EBS
13/05/2018 13:28
Timing went well, 7+3 was better than 10+1
Keep doing 7+3 timing
What needs improvement? Used timer less Research time How can we improve this? Timer: try to keep to the process Implement research time in plan for the day
It’s nice to switch often, but still sometimes it feels like the time goes too fast. We lose the flow 11
How can we improve this? We suggest that sometimes we can be more independent of the timer, and use it like a guideline. Another suggestion is to try a day without driver, and try to find a fitting time to switch (ie: the one with the thought, shall not drive) 12
EBS
17/04/2018 14:28
13
EBS
17/04/2018 14:28
Sometimes the timer is useful, but other times it’s hindering progress.
Try to be more flexible with changes. Timer is to keep us reminded, but we should change more when we feel for it. 14
EBS
17/04/2018 14:42
15
EBS
17/04/2018 14:46
16
EBS
17/04/2018 14:54
17
EBS
17/04/2018 14:54
We worked without timer today, which felt nice and chill in a way What needs improvement? We were driving for too long How can we improve this? Reinstate the timer regime Use timer with max limit
We could have switched driver more often.
We did not switch roles often enough
Try to switch every time a feature has been implemented including related methods and sub-features
Reports\\Coding Summary By Node Report
Page 54 of 62
APPENDIX C. THEMES FROM ANALYSIS
100 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
18
EBS
17/04/2018 14:55
1
EBS
12/05/2018 10:06
2
EBS
12/05/2018 10:06
What needs improvement? Driver switching How can we improve this? Switch more often
Internals\\Elias Sørensen Diary No
0.0435
3
2018-02-23
I felt like I got alot of stuff done today. As we switched drivers, code was written swiftly, and new components added with relative ease. I think we have found a decent timing with 7+3, and it feels like I’m productive. 3
EBS
23/04/2018 13:08
I felt today, with mob programming again, was nice. We had decent progress, and didn’t face any major problems. We didn’t use a timer at all today, which felt more relaxing. I felt I, and my teammates were useful
Internals\\Ole Kristian Aune Diary No
0.0321
1 1
EBS
12/05/2018 09:18
Worked well with the process, it gets more and more natural, and I notice the new timing with 7 minutes followed by 3 minutes to finish up and change driver, works much better than 10 minutes on, 1 minutes change.
Internals\\Video transcriptions No
0.0542
5 1
EBS
10/05/2018 11:01
At video 2 0,7:02 there was another remark from Ole as the developers switched chairs: Ole: We haven’t set up a timer yes, but that’s all right Elias: Yes, we could fix a timer then Ole: We can fix that Christian: So we can Ole Should we do that first? Elias Yes, do that. Download.
Reports\\Coding Summary By Node Report
Page 55 of 62
APPENDIX C. THEMES FROM ANALYSIS
101 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
2
EBS
12/05/2018 09:40
At video 0122, 14:15 The timer is discussed Transcript: Elias: "Work interval, 10 minutes" Christian: "Break could be." Elias: "25. Long break after... " Ole: "But do we want 25 minutes?" Elias: "How many intervals during a day? Since it’s ten minutes, it will be... Christian: We won’t bother to calculate that Ole: No, we can change it Elias: That would make it.. Ole(reading from the timer program settings): Work completed sound, alarm clock, end break sound. (mumbling) Elias: That would be 50 intervals then Christian: Sure. Ole: It doesn’t matter. Complete notifications (mumbling). Elias: Should we have autostart timer? Ole: No 3
EBS
10/05/2018 11:05
4
EBS
13/05/2018 10:52
Video 010122 At video 010122, 06:25 Comment about driving time Ole: Then I’ve got three minutes and 45 seconds left Christian: That’s kinda short Ole:, Yes, but it’s supposed to be like that Elias: Everyone’s supposed to feel like they’re writing all the time Stopped at 7:28 video 010122
Ole: Yes well... ...I know where we start Christian: Then you shouldn’t be the driver Ole: No, but I guess I just have to explain a bit to you Christian: ...No...you shouldn’t drive. Elias, do you want to drive? Elias: I could very well drive Ole: Okay, you won’t get to write so much right away, because there’s some stuff I must go through. (Elias and Ole switch seats) Elias: Is the keyboard connected? 5
EBS
13/05/2018 10:52
Video70124 2018-02-05 10:40 ( The timer beeps for switch while the team discusses folder and package structure, and Elias and Ole switch places. The switch seems to break the work flow. Elias becomes the new driver) Ole: Who is it? Christian: But we need the package first, it’s you Elias Elias: It’s me? Okay. Elias: Then we continue where we left off. Now it’s no longer me who decides what happens Christian: You can still participate in the decision making Elias: Yeah, I’ll come with input and discussion, but uh.
Reports\\Coding Summary By Node Report
Page 56 of 62
APPENDIX C. THEMES FROM ANALYSIS
102 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
1
EBS
14/05/2018 14:16
Nodes\\Work Atmosphere Document Internals\\2018-03-06_Sprint retrospective No
0.3128
2
This can be achieved by first telling the driver the goal of the work session. Instead of guiding for every line. This means the driver knows what to do and can work fairly independently instead of being forced to write every line by listening to others. This gives more freedom and prevents annoyance. 2
EBS
14/05/2018 14:16
This can be achieved by first telling the driver the goal of the work session. Instead of guiding for every line. This means the driver knows what to do and can work fairly independently instead of being forced to write every line by listening to others. This gives more freedom and prevents annoyance.
Internals\\Christian Echtermeyer Diary No
0.2335
10 1
EBS
14/05/2018 14:16
Our work didn't start before around 12:30 due to working on another project (CCD) and therefore we decided to work untill 18:00. I am very exhausted after todays work, maybe because it is monday, maybe because we worked late just setting things up which i am not a fan of. I feel the team worked well today and we got work done, although my mood was declining towards the end and did not match my fellow teammates. 2
EBS
17/04/2018 15:17
The mood of the team in general was fairly good although my view of working late today was met with a bit of resistance. 3
EBS
12/05/2018 09:23
My experience of the day was fairly good, although feeling slightly tired towards the end of the day the mood was good and the team worked well 4
EBS
23/04/2018 11:15
5
EBS
14/05/2018 14:16
Its been a good week so far and my mood is good
I have slight trouble keeping focus when working with set-up since it is really boring when it keeps failing. We didnt really follow the process too tightly either as a whole lot of time was spent simply waiting for builds to pass or fail, or doing research on what might work. I hope we will get things going again tomorrow 6
EBS
23/04/2018 12:23
11:30 was the official start time of the day, so we started with a good lunch and mood was good. We started off slow trying to fix an error from the day before, but once we got that fixed things were smooth sailing. 7
EBS
23/04/2018 12:25
8
EBS
12/05/2018 09:31
Overall this was a nice and short day and a decent end to the week.
We started worked on more front-end views and refactoring. Things went smoothly and i felt we got a lot of work done and we are well ahead of schedule on the sprint. Working on the views is fun and yields immediate results which are good for the mood. We did not hit any huge errors today and since we got started so well we decided to work an hour extra. I felt this day went quite good and the team worked well. Reports\\Coding Summary By Node Report
Page 57 of 62
APPENDIX C. THEMES FROM ANALYSIS
103 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
9
EBS
23/04/2018 12:33
Once we got it solved things seemed to go very smoothly, even things that at first seemed difficult ran on the first try which is very rare. The mood of the team was a bit mediocre at the beginning but now at the end of the day i myself and i believe the team aswell feel we ended on a high point and are ready for tomorrow 10
EBS
23/04/2018 12:36
1
EBS
17/04/2018 14:04
2
EBS
17/04/2018 14:05
3
EBS
17/04/2018 14:05
4
EBS
17/04/2018 14:22
5
EBS
17/04/2018 14:43
6
EBS
17/04/2018 14:44
1
EBS
14/05/2018 14:16
Today was a good day and the mood was good.
Internals\\Daily retrospectives No
0.0129
6
Good mood and atmosphere.
Have fun while working!
We had fun
Was a fun day
Team spirit was high and it was a good work day
Getting things done efficiently and with a good mood.
Internals\\Elias Sørensen Diary No
0.1788
8
formatting was immediately set to our preference because we debated how it was supposed to be. At times however, as driver, I felt that the navigators maybe took a bit too much detailed control. This happened because I had a way I usually generated code, but they were used to another. After learning my teammates’ way however, that specific conflict might not happen again. 2
EBS
23/04/2018 12:50
. Work went well today, and we had fun programming together. The spirit was high during the whole session. We were more self aware, and took into consideration what we had from yesterday’s retrospective 3
EBS
14/05/2018 14:16
I think the whole team was kind of slacking today, but since it concerned the whole team, it wasn’t that bad. We didn’t get as far as programming today, so I didn’t feel like we did much useful. On a day like this I felt like I could’ve done lots of other useful things than try to fix those docker problems
Reports\\Coding Summary By Node Report
Page 58 of 62
APPENDIX C. THEMES FROM ANALYSIS
104 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
4
EBS
14/05/2018 14:16
Today we worked with setting up an optimized contiuous integration, as the slow build was hindering progress in our work, because everyone has to wait for the build. We had no success in fixing it completely, but had some promising tries. It was demotivating to only work with setup again. I had long periods of time where I really felt I could have been of better use doing other stuff 5
EBS
12/05/2018 11:38
Today I felt we had one of the most efficient days as of yet. Progress went swiftly, and we merged several components. I also had lots of fun along the way, and lunch seemed to appear suddenly. 6
EBS
23/04/2018 13:05
Today was another great day. We spent something like two hours on a small syntax error none of us was able to spot early. Other than that I felt like things were great. 7
EBS
14/05/2018 14:16
8
EBS
12/05/2018 12:10
I got really frustrated with the error we had, but finally solving it was satisfying.
We also had fun at some points, and celebrated when we made new features work, which produced motivation and joy.
Internals\\Ole Kristian Aune Diary No
0.1242
3 1
EBS
23/04/2018 14:31
Today was a very productive day. We implemented all rest api endpoints for user and added lots of tests. It all went really smooth and collaboration worked really good. No major set backs and lots of progress. All in all very happy with how smooth the system worked today. 2
EBS
23/04/2018 14:33
We had a really good session after lunch, and I feel we are good on track for this sprint although last sprint ended under the goal (it was way too ambitious). Looking forward to some frontend work the coming days. It’s the part I like the most, and find most rewarding. Hope I feel the same way when mob programming on this task also. 3
EBS
23/04/2018 14:37
A little tired as usual at the end of the day, but all in all a good day. Unfortunately we have some problems with videotaping, but it was the right decision not to use time on it, and instead keep pushing the project forward
Internals\\Video transcriptions No
0.1222
11 1
EBS
10/05/2018 11:09
2018-02-02 At 08:22: Fixed a typo done by the driver Christian, who remarked that the error should have been caught by the navigators. Ole: Should we write it every time there’s an “Echter-bug”? Elias: *Laughs* Christian: No, the “Echter-bug” is a part of you, because you guys didn’t catch it. Elias: We should’ve caught it Ole: That’s true actually Elias: Now we cannot blame, now we can’t point fingers and stuff
Reports\\Coding Summary By Node Report
Page 59 of 62
APPENDIX C. THEMES FROM ANALYSIS
105 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
2
EBS
10/05/2018 11:23
23:28 (Approx. 20 Minutes starting session with help Øystein. Elias and Øystein are currently casuallt chatting while Ole is the driver, trying a new solution) Ole: So if we now try... Elias: I suppose “drifters” maybe have a bit more of such shellscript programming Ole(typing): We must run it again.. Øystein: Well, the whole thing where you make tooling and such things. It is...the developer should be able to make tooling, make deploy tooling and such things. And then you have to do programming with shell script Elias: Yes, to do it as easy as possible to work Øystein: To make it possible Elias(laughs): To make it possible Christian: Heey, it worked Everyone(celebrating, stretching hands into the air) Ole: Test exited with code 0. Christian: That was what we wanted Ole: It sounds very promising. Øystein(nods and gives a thumbs up): That is what we like 3
EBS
10/05/2018 11:43
4
EBS
10/05/2018 11:50
2018-02-15 Video0129 16:36 Elias: And then we say that “srid” instead is… that’ an int actually *Elias and Ole are laughing* Ole: Int and long and… Elias: Well look at that Ole: Yeah, here there is no consistency Elias: It was late in the night okay? Ole: Yeah, that’s allright. That is very good. I was ill, so.
Video50129 2018-02-15 03:10: (The team laughs because Christian types something weird on the Windows keyboard that has been wrongly mapped from the Mac. ) Mention from Ole (referring to the Mac keyboard): It might have been faster for you to learn that keyboard. 5
EBS
14/05/2018 14:16
6
EBS
14/05/2018 14:16
7
EBS
14/05/2018 14:16
03:38: (Both Ole and Elias cry out as soon as Christian types something wrong. ) Elias: Spacing Ole: You must have spacing there Christian: I will fix it after
Video 110135 2018-02-21 04:42 (Elias is driving) Ole(points on the screen): Could you take space with the equals? Elias: I was on my way there Ole: Okay, nice. Because I like this a bit more. Just like.. Christian: Space there too. On the bottom Ole: Mhm Elias (types as instructed) Ole: Newline was what he wanted. Before “Component did mount” Elias (slightly bothered) : Ah okay. Space, newline. They blend into each other
2018-03-15 Pair programing Christian and Ole
Reports\\Coding Summary By Node Report
Page 60 of 62
APPENDIX C. THEMES FROM ANALYSIS
106 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
8
EBS
14/05/2018 14:16
9
EBS
10/05/2018 13:10
2018-03-22 Video30143 02:10 (Christian is writing report, Ole and Elias are pair programming) Ole (regarding Docker, talking to Christian): You miss this don't you Elias: Run it Ole: Do you miss this (once again talking to Christian) Christian: Hmm? (Looks at screen) Christian: No (smiles)
2018-04-03 Video 0145_1: 17:20 (Elias got a weird text selector instead of standard by accidentially typing a keyboard shortcut) Only Ole is used to programming on a mac Ole: I dont know what you are doing right now. Christian: (Laughs lightly) Elias: What is this... I dont understand Ole: I dont understand what you are doing either Elias: (Enables a weird mac setting and is unable to get rid of it) All: Laugh Elias: What is this Ole (laughing) 10
EBS
10/05/2018 13:53
Video 10169_1 2018-04-24(Continuing to fix the search issue, Elias is still driver) Elias(refers to searching for the number 300 while the item is 300 too): Here we have 300 and 300 Ole: You have 300 longer up too. Elias: Woho! It worked then. Ole: Like ish Elias: Maybe we should take “contains” then Ole: Yes, that’s what I’m thinking.
Reports\\Coding Summary By Node Report
Page 61 of 62
APPENDIX C. THEMES FROM ANALYSIS
107 15/05/2018 18:18
Aggregate
Classification
Coverage
Number Of Coding References
Reference Number
Coded By Initials
Modified On
11
EBS
11/05/2018 12:25
Video 10169_1 2018-04-24 01:30 Elias: A number can’t contain another number. The thing is that we must convert them to strings. We musk make sure the numbers are strings. Couldn’t we say.. how Ole: I’ll look it up. Elias: I have a way meanwhile. A quick-fix. Elias(refers to what he’s typing on screen): You take that plus that Elias(laughs): Ole(glances at the screen): No Elias(smiling): This is a hack. Just to check that the.. Christian: I don’t think that will work Elias(keeps typing): Why won’t it work? It is a string now. Christian(laughing): This is fricking hacky Elias(typing and running the result): He-he-heyyyy Christian and Elias (laughing) Ole(shakes his head) Elias: The problem is that we’re searching with number equals number. If we don’t have any static types in javascript, we just have to hack around a string. Elias(keeps laughing) Christian: Well yes Elias: This worked Christian: It worked pretty well, too. Elias(laughing some more and takes a sip of coffee) Ole(keeps searching) Christian: It was fast too Elias: This was fast, Ole. Elias(jokingly): This is like it’s meant to be Ole(refers to the source in which he’s reading): The worst is that some people here say “take the number, and add an empty string”. (Everyone laughing)
Reports\\Coding Summary By Node Report
Page 62 of 62
