Older adults and hackathons: a qualitative study

Abstract

Globally observed trends in aging indicate that older adults constitute a growing share of the population and an increasing demographic in the modern technologies marketplace. Therefore, it has become important to address the issue of participation of older adults in the process of developing solutions suitable for their group. In this study, we approached this topic by organizing a hackathon involving teams of young programmers and older adults participants. Below we describe a case study of that hackathon, in which our objective was to motivate older adults to participate in software engineering processes. Based on our results from an array of qualitative methods, we propose a set of good practices that may lead to improved older adult participation in similar events and an improved process of developing apps that target older adults.

1 Introduction

Demographic prognoses developed by the U.S. Census Bureau indicate that in 2050 the population aged 65+ in the USA will almost double and reach 83.7 million (over 20% of the society) (Ortman et al. 2014). A report prepared by OCED (Nations 2015) shows that Japan will be the oldest society by 2050. With the trend of aging visible in developed countries, older adults become a larger section of the market. This extends to ICT as well. With the increase in number of elderly users of mobile devices and apps, it is important to optimize the process of developing solutions that would suit the needs of this demographic. In this article we present, through a case study setup, observation on how older adults can be incorporated into development teams in order to create valuable software using bottom-up approach and participatory design alongside with rapid development and agile techniques. This case study would be carried out during a DevMuster hackathon organized in Warsaw, Poland, by the Polish-Japanese Academy of Information Technology. During this hackathons older adults were invited to participate in the work of contestant teams. It is one of many hackathon events organized in Poland, but to the best of our knowledge it is the first hackathon in the world to actively involve older adults within the work of teams throughout the whole process- from idea development stage to final application tests (according to a recent survey (Briscoe and Mulligan 2014), hackathon participants aged 54 and older are about 1% of all participants). Such setting allows for studying the interactions of people of different age and social groups in a created environment for agile software development. This in turn provides insight into how social interaction within a multigenerational development teams evolves and what is the process by which such teams create new software. The case study design also offered a possibility to view what challenges may arise when organizing events of this type, and what can be done to overcome them.

1.1 Research Objectives

The aim of our case study is to review the effects intergenerational cooperation has on software development teams. These effects would be observed within a participatory design approach, where the end users take part in the design stage for the application. In order to address this issue, we created a set of objectives that our case study aimed to meet. These can be described as the following:

• 1. Observe the dynamics of social interactions within the development teams between older adults and junior developers:

  • (a) How do interactions begin? Who initiates them?

  • (b) How strong is the collaboration between the two age groups?

  • (c) How do the attitudes between generations change during the event?

  • (d) How does the cooperation conclude?

• 2. Explore the extent to which participation of older adults affects the development process and verify participatory design approach:

  • (a) How do members of the two generations view their role in application development?

  • (b) What aspects of software design are presented to the older adults by the juniors?

  • (c) Does the mode of cooperation between older adults and juniors affect the software quality?

  • (d) How do the stereotypes about the elderly affect the design process?

Although we do not aim at proposing a complete methodology for engaging older adults into the software development process as postulated by Nicol et al. (2015), findings presented in this paper might lay the foundation for further work on such a methodology.

1.2 Motivation for Choosing Hackathon as an Object of Study

In the last few years there have been many discussions about current trends in software development. Some researchers like (Lindsay et al. 2012) or Davidson and Jensen (2013) point out that there is more to the discussion about participatory design with older adults than the dispute on the new key trend in HCI, the third wave. One of the fundamental underlying ideas is related to the need to continue the research and present new examples on participatory design leasing to broader acceptance of the practice in industry. It can also be vital to dispelling harmful stereotypes regarding older adults cooperating directly with younger participants. We chose the Hackathon as setup for this case study and for observation of team members’ participation. It was dictated by several methodological considerations related to our research questions. The context of those fundamental research concepts is described in detail in the following section.

Firstly, since commercial development teams are rarely created based on the age factor alone, it would have been extremely difficult to find a sample of teams with a significant age difference between the team members. Choosing the hackathon allowed us to study 25 teams of software developers who had the possibility to interact with older adults. Developers were able to make autonomous decisions about the inclusion of older adults in their teams, but were not constrained by the need to recruit older participants. For this reason, the hackathon setting served to create favorable conditions for participatory design of applications for older adults.

Moreover, studying intergenerational cooperation in an industry environment poses other problems that can influence the results of a case study. Each industrial project team works within an established management framework (ie. Agile) and has its own development practices or established collaboration patterns. Interactions in such team can be strongly influenced by these team-specific aspects. Therefore, observations of intergenerational cooperation made in the industrial context would be hard to generalize. Hackathon offers more opportunities of observing various teams with various development practices, interaction styles and experience.

In a case study of a project within an established business context the observations can be made at a specific point of the project’s development cycle. However, a case study of a hackathon designed and conducted by the researchers offers a unique opportunity of observing the full dynamics of a team from beginning to the end of its existence. Furthermore, due to the time constraint inherent in every hackathon, the main focus of the team’s work is the idea development stage. Most of our research focuses on intergenerational cooperation in designing ICT solutions, rather than implementing them, therefore a hackathon setting offers more opportunities for an in depth observation.

The choice of a Hackathon as a case study for investigating the collaboration of older adults and programmers does have some limitations, which are discussed in more detail in Section 6.4.Still we concluded that the advantage of studying a larger number of programmer teams that involve older adults outweighs the potential disadvantages in various ways. The findings reported in this article are limited to the hackathon settings, but may be generalized for the benefit of future research.

The rest of this paper is structured as follows. Section 2 outlines the background of our research in the context of the related work. In Section 3, we present the tools used for data collecting and analysis, as well as the description of the case study setup. In the Section 4, the observations made within our case study are being made, with regards to each of our set research objectives. Section 5 contains a brief description of application delivered by the participating teams. Section 6 discusses the conclusions the we made during our research, as well as some good practices for conducting such events with older adults.

2 Related Work

In this section, we briefly outline the background of our research from the perspective of current trends in software engineering with respect to broad design approaches. We emphasize the social interaction aspects, use qualitative software engineering methods and tools, and take a close look at hackathons as our case study research setup. In all of these areas, we were looking for research that addressed research questions similar to ours: concerning the interaction of older adults with software developers, or the design of applications for older adults.

2.1 Key Design Concepts: from a User-centered Approach to Participatory Design

The human perception of technology has become a crucial issue today, because technical quality and price factors have become more competitive in the market (Sanders and Stappers 2008). Unfortunately, the relationship between technology and some key concepts such as user experience and various design approaches can be complex and sometimes difficult to define. It is worth mentioning that despite current discussion about trends in software development, in particular about the differences between second and third wave of HCI, many authors, like (Lindsay et al. 2012) or Davidson and Jensen (2013) claim that the most important challenges of current studies on participatory design with older adults are connected to addressing their real needs and desires instead of simply tackling their most obvious functional impairments. However, they say that experience-centered design also plays an important role in relation to work with older adults. Therefore, in the following subsections, we focus on the related context vital to our case study.

2.1.1 User Experience

User experience is a popular term within the human-computer interaction and software engineering communities. It is frequently used in the context of agile development and rapid prototyping. User experience is defined in the International Organization for Standardization (ISO) standard (ISO 9241-110:2010) as a person’s perceptions and responses resulting from the use and/or anticipated use of a product, system, or service (ISO for Standardization IO 2010). This definition shows that the term can encompass a wide variety of often blurred and overlapping attributes and perspectives (Law et al. 2008). (Hassenzahl and Tractinsky 2006) briefly overview the many variables that can be applied when considering user experience in designing a product, from esthetics to the human emotional response. Surveys of UX practitioners conducted by Law et al. (2009) and Bargas-Avila and Hornbæk (2011) further describe the myriad of variables that must be considered within this approach to the product design. In the survey by Bargas-Avila and Hornbæk (2011), most UX practitioners say that, due to the individual nature of user experience, efforts to standardize procedures may have limited efficacy. Approaches to the design of user experience must also be differentiated from the more traditional approaches of ergonomics or usability, although the exact boundaries of the division continue to be a matter of academic debate (Hassenzahl 2008; Bargas-Avila and Hornbæk 2011; Tuch et al. 2012).

Keeping in mind the distinction between user-centered and participatory design described in details in next subsection, it is important to note that diversity in user experience extends to its evaluation methods as well. Among the methods of evaluation applied in this field, we can list experimental setups (Hassenzahl 2008), quantitative methods such as surveys, and qualitative approaches such as ethnographic studies (Karapanos 2013) as well as case studies (Roto et al. 2009). However, most of these methods focus on a relatively small group of users who are presented with a product in a given scenario. We decided to employ a variety of these methods, discussed in details in the methodology section, but with a larger group of participants. Thus, this approach is still qualitative and therefore more comprehensive than other UX testing methods e.g., typical A/B tests.

2.1.2 Participatory Design

Apart from the aforementioned limitations and difficulties, user experience is inevitably and strictly connected to the concept of user-centered design as an aspect of the general idea of human-focused approach. This approach is related to another important idea: participatory design, which is sometimes known as co-design.

Although these terms have different origins, they refer to the same bottom-up approach, which is widely used not only in software engineering but also in fields ranging from architecture and landscape design to the healthcare industry (Szebeko and Tan 2010). These concepts put human beings at the center of the design process, although there is a small but significant distinction between user-centered design and participatory design: the former refers to the process of designing FOR the users, while the latter refers to designing WITH the users Sanders (2002), Sanders and Stappers (2008). According to Sanders and other researchers the next step in participatory design will be the process of designing BY the users themselves. She also claims that participatory approach can be applied throughout the whole design cycle, including the pre-design stage.

On the other hand (Ladner 2015) limits the scope of participatory design to just two of the four stages of this iterative cycle of product and software development: design and testing (excluding analysis and prototype stages). He limits user-centered design only to the testing stage.

These broad concepts may refer to the many facets of software engineering process and design approaches, which themselves can be fairly complex and difficult to define. In particular when evaluating interactions between older adults and software, most of the efforts have been focused on product design to address the physical and cognitive aspects of aging. Ethnographic studies on the use of computing techniques by older adults suffering from Alzheimer’s disease (Morris et al. 2003), older adults’ experiences with rehabilitation tools (Morán et al. 2014), and mobile technologies in general (Lee 2007) as well as the problem of learned helplessness, which has been observed among older adults who interact with ICT devices (Turner et al. 2007) are some of the examples of the experience-centered approach in application design.

Apart from some differences in definitions and scopes, human-centered design is undoubtedly crucial to the development of sustainable solutions as an idea which, according to Ladner and other authors, underlies universal design and ability design. Both approaches are vital in HCI and directly connected to older adults in terms of facing the disabilites and transforming them into impairments that can be properly addressed according to the social model of disability such as that proposed by Oliver et al. (2012). On the other hand it was mentioned before that according to Lindsay et al. (2012) and Davidson and Jensen (2013) designing the solutions for older adults should not be treated as addressing the list of identified functional impairments but rather as an opportunity to explore their needs and desires. Moreover, Lindsay et al. stipulate the early engagement of older adults in design process cycle regardless the area of design. This approach together with previously mentioned claims and solutions proposed by other authors i.e. Convertino et al. (2005) encouraged us to employ the participatory design approach from the very first stages of the development process, namely the pre-design stage of our study(idea development).

The theoretical principles of participatory design can be applied to the problem of designing applications for older adults. In literature, there are also many examples of practices of involving older adults in the participatory mode of mobile app development (Kankainen and Lehtinen 2011), Massimi et al. (2007); however, some of them were narrowed down to health related issues and conducted in a more user-centered development mode rather than a fully participatory mode (Lorenz A et al. 2007). In our case we did not want to focus on health related issues, therefore we invited a group of active older adults from our LivingLab, which is a framework project dedicated to older citizens run in cooperation with the City of Warsaw (Kopeć et al. 2017). The details of the recruitment process are described in the methodology section.

Based on previous works and experience (Lindsay et al. 2012) we proposed a systematic approach for participatory design called OASIS, which stands for Open architecture for Accessible Services Integration and Standardization. Lindsay’s UK-based team verified a simple and general approach consisting of four stages: 1) identification and recruitment of stakeholders, 2) creation of special video materials for better engagement of older adults, 3) exploratory group meetings and 4) low fidelity prototyping. This approach was independently verified by Davidson and Jensen (2013) in the US. Both teams reported that involving older adults in participatory design is worthwhile and useful, especially in terms of keeping the costs at minimum and fostering the development process. This approach bears similarities to our process in terms of early end-user engagement, however we chose to make use of different dynamics in preparing the target group of end-users to participate in software development process. In our case we focused on recruitment of more advanced users to foster the process of direct involvement in participatory design process of mobile applications development and therefore answers to the call formulated by both mentioned teams to the research community for making more efforts with hand-on experience and direct interaction between teams and end-users.

The approach of directly involving older adults in the participatory design process benefits not only designers but it also empowers the end-users, and therefore brings us a step closer to the mentioned postulate by Ladner of design for user empowerment. This is important also in terms of facing stereotypes, namely ageism which according to Joyce et al. (2007) plays a significant role in the discussion of involving older adults in the technology design process. Joyce performed a study involving technology, science, and ageism, and concluded that technology design is indeed ageist and technologies such as computers and the Internet are designed predominantly for younger people, thereby excluding older adults from comfortably using these technologies. Other authors like (Ryan et al. 1992) claim that older people are frequently inappropriately depicted as being resistant to technology. On the other hand (Wilkowska and Ziefle 2009) show that the gap between younger and older adults in engagement into new technology can be overcome. This conclusion is also coherent with our previous experineces from LivingLab, i.e. location-based game (Kopeć et al. 2017).

Summing up, many authors find direct involvement of older adults in design process in participatory mode to be a low-cost approach that facilitates the process of software development, particularly the development of mobile applications. Furthermore, this approach is seen as rewarding for both parties involved in the process, i.e. designers and end-users. Alongside with mentioned research postulate of the need to deliver more successful engagement in participatory design, especially in the field of direct cooperation between the teams and the older adults as end-users, these conclusions led us to explore that area of software development. Having in mind the younger population and the existing stereotypes, especially ageism, we have decided to directly expose younger teams to older adults from our LivingLab in order to foster the process and make use of our previous positive results of intergenerational cooperation between younger and older adults (i.e. location-based game) alongside with moving the focus from health-related problems to the broader context of everyday life of older adults as postulated by many authors including (Lindsay et al. 2012; Ladner 2015) and Davidson and Jensen (2013). In order to better prepare our case study we also examined the area of qualitative studies and hackathons with regard to team diversity. The literature review in those fields is depicted in following subsections.

2.2 Qualitative Study of Software Engineering

The use of qualitative studies (and the case study method in particular) as a software engineering tool is a developing field. To date, sets of guidelines have been developed for conducting effective research within the context of software engineering. One of the first papers on the application of this methodology was published by Seaman (1999). Authors proposed a set of research methods for conducting qualitative research in software engineering. These methods focus on the nontechnical facets of software engineering that fall outside the scope of the standard tools of software engineering. Inspiration for these guidelines came from previous work by social scientists (Taylor and Bogdan 1984; Malterud 2001; Miles and Huberman 1994; Glaser et al. 1968). It is also worth mentioning that according to Yin (2015) various qualitative methodologies can overlap, in particular a case study can be based on participant observation.

Since then researchers have addressed various aspects of the case study methodology within the context of software design, mostly with the aim of defining best practices and guidelines. Runeson and Höst (2008) provided a list of best practices. In another study, Shull et al. (2008) focused on a specific method of qualitative research. Three main types of qualitative studies have been defined in the literature (Runeson and Höst 2008; Seaman 1999; Robson 2002; Wohlin et al. 2012): surveys, experiments, and action research (some also include ethnographic studies in which there is a focus on conducting field work to consider user and developer experiences (Easterbrook et al. 2008). According to Marshall and Rossman (2014) one of the main purposes of qualitative research is exploration. The important aspect of qualitative methods is that unlike quantitative methods, they go beyond the description of observed phenomena to include the potential for exploration, which allows for the discovery of otherwise unseen processes. For example, Rainer and Hall (2003) applied a mix of quantitative and qualitative methods to identify 26 most important factors affecting the software development process.

Another important factor to consider while conducting qualitative research in the field of software engineering is the relationship between the researchers and those participating in the study. Carver et al. (2003) reviewed issues relating to the participation of students, researchers and members of industry when carrying out qualitative research. Among conclusions important for our case study were those related to proper motivation of participants without revealing the goals, measures and analysis to them prior to executing the study. Another conclusion was to avoid conflicts with other commitments of students. We tried to address these issues by choosing a proper and compact form for our case study.

Qualitative studies have also been applied to the interactions between members of inter-generational groups in which ICT played an important role. One good example is the work by Convertino et al. (2007) who discuss methodological problems and findings that can be extracted when researching the interaction of older and younger adults in computer support groups. They emphasized the difference between lectures and personal experience methods. Another interesting example is the study by Schloegel et al. (2016) related to reducing age stereotypes in inter-generational groups of developers working in the same enterprize.

2.3 Hackathons as a Qualitative Case Study Tool

The term “hackathon” is a combination of the words “hack” and “marathon.” Hackathon can be used to describe an organized software engineering event in which programmers and other specialists involved in software development convene and form teams to work intensively to solve a given task. The most popular hackathon format is the one in which the teams are given 24 hours to prepare a working prototype of a software program designed to solve a given problem. These problems may range from specific apps, to games, to solving performance issues. A comprehensive review of the various types hackathons was performed by Briscoe and Mulligan (2014), who also developed a compelling hackathon classification scheme with respect to their themes and main focus.

In general terms, hackathons can be divided into main fields of study, each with its own set of objectives. The first is the field of software engineering. Research involved in hackathons pertaining to software engineering is focused on the potential impact that a hackathon can have on improving the application development process. Most work on this topic is in the format of field work reports that formulate best practices. A good example is the work by Lapp et al. (2007), who conducted a field study of a hackathon event organized to develop bioinformatics solutions. The results provided insights on prioritizing the issues to be addressed and by moderating the programming teams during the creation of apps. Another approach was considered by Dehli (2016) who collected evidence from THE Port 2014 Hackathon and determined that the participation in teams at such events improves the likelihood that start-ups will sprout. However, these findings are mostly preliminary observations. Research by Trainer et al. (2014) suggests that strong empirical evidence for the effectiveness of hackathons in software engineering has yet to be produced.

The other field of study with respect to hackathons can be broadly described as being focused on their sociological aspects, which can range widely depending on the issues being addressed. One of these issues has been the effectiveness of hackathons as an education tool (especially, science, technology, engineering, and mathematics education – STEM). A good example of this research is the work by Nandi and Mandernach (2016), who argued that hackathons are a viable informal learning method for students. The fact that peer-learning, in the form of mutual aid in solving various problems, was observed to occur among the participants despite the competitive nature of the event was the one of interesting findings of this study. The importance of organizer and mentor support was also emphasized. A similar argument for hackathons and game jams was made by Fowler (2016).

2.4 Team Diversity

Another theme in the sociological study of hackathons is the analysis of the impact the structure of these events has on diversity and minority participation. The problem of gender inclusiveness was addressed in the already mentioned review by Briscoe and Mulligan (2014), where it was noticed that women are underrepresented among the participants of hackathons. More researchers such as Elsass and Graves (1997) found that hackathon teams which include diverse groups such as women or people of color suffer from lower performance than more unified group. Researchers suggest that within a tight time constraints of the hackathon, participants tend to categorize other team members based on their salient features. This also increases the likelihood for the group to suffer biases (Turner et al. 1987; Hogg and Terry 2000). It is a theme visible also in other aspects of IT project management (Seron et al. 2016). Team diversity has also been found to have a positive impact on quality of collaborative teams in online knowledge communities like the Wikipedia (Wierzbicki et al. 2010; Turek et al. 2011).

The problem of team diversity, and group representation within the framework of a hackathon team (especially in the context of intergenerational cooperation) can be generalized to the problem of intergroup dynamics, and development of social identity. This topic was described and analyzed in the well established models presented by Tajfel in his various publications (Tajfel 2010, 1974, 1981). In context of an intergenerational teams, the cognitive aspects of group categorization mentioned in the given model are very important, since the ones self-perception of technological aptitude, as well as socially established stereotypes (eg. stereotype of older adults not being skilled with ICT) may affect the participants motivation to cooperate with team members belonging to a different generation.Research into group identity and motivation done by Haslam et al. (2000), although not related to intergenerational aspects, corroborates this notion, by showing that salient social identities strongly affect the individuals motivation. Work by Ashforth and Mael (1989), shows how social identity, and stereotyping can affect interactions in the context of an organization.

Some work was done toward addressing this issue. A prime example would be a StichFest, hackathon event organized and later described and researched by Richard et al. (2015), during which novel problems connected with combining software solutions into drones and wearables were implemented into the event, together with a wide range of mentoring services and cooperation fostering. Filippova et al. (2017) proposed brainstorming as an efficient method to overcome negative consequences of team diversity during hackathon-like events.

Also noteworthy is the research on the emergence of group cohesion, and social dynamics during the lifetime of a hackathon team. A very interesting approach in this area was made by Jones et al. (2015), were the linguistics aspects of inter-group communication in teams of hackathon participants, work toward their cohesion and dynamics.

Although, due to socio-cultural conditions many aspects of team diversity do not apply to our study, the age factor still remains important. Within our study we also aimed to find if stereotypes played a role within idea development and what this role was like.

Last but not least is the study of the interdisciplinary potential of hackathons as platforms for networking and the exchange of perspectives between representatives of various business and academic fields.

3 Methodology

In this section, we describe the case study setup and tools we used to obtain data. In the “Study design” subsection, we describe our implementation of the case study and our considerations while preparing for and conducting the research. Moreover, in the subsection “Analysis Tools,” we detail the tools we used and our rationale for doing so.

3.1 Case Study Design

Case study is one of the most important exploratory approaches in qualitative research (Rossman and Rallis 2003). It can incorporate various overlapping qualitative methodologies (Yin 2013; Zucker et al. 2009) including primary methods like observation and interviews as well as supplemental techniques like questionnaires and surveys (Marshall and Rossman 2014).

3.1.1 Hackathon Setup

When designing the event, we had to consider the needs of older adults both as the target user group and as participants in the software design process. We invited older adults active in our LivingLab–a distributed laboratory project initialized, developed and implemented at Polish-Japanese Academy of Information Technology and run in cooperation with the Municipality of Warsaw (Kopeć et al. 2017). Goals of PJAIT LivingLab refer to the vital issues of social informatics related to aging, including the improvement of social inclusion of older adults, their technological skills in the area of mobile technologies, motivation for learning as well as physical well-being, due to a positive intergenerational interaction.

The recruitment process of younger participants started three weeks before the event. They registered directly via a form on the event website. They were recruited using the official hackathon website as well as PJAIT webpage, mailing and social media alongside with a traditional press release.

In order to better cater to the needs of the invited group of older adults, we consulted them during a preliminary discussion two weeks prior to the event. Then we presented and explained the research topic to older adult participants and engaged them in discussions about any concerns or suggestions pertaining any aspect of the hackathon. The older adults were eager to participate in the hackathon. We told them that they would be working in pairs in programming teams (they could choose a team partner before the event or on the spot). Their assignment to the programming teams occurred immediately following the opening presentations of the hackathon (at 7.00 pm).

We explained to the older adults that they were not required to stay with the programmers for the entire 24 hours of the hackathon. To avoid any problems with respect to communication during the evening hours, we offered taxi services, paid for by the event organizer. We emphasized the importance of cooperation between the elderly participants and programmers during the first and last stages of the hackathon. We also explained that remote contact was possible during the middle stages of the hackathon. The older adults proposed that, through the night, after establishing initial cooperation in person, they could communicate with the team via e-mail or SMS.

The main concerns expressed by the older adults were their doubts concerning their own technical aptitude. To address this concern, we explained that their technical skills were less important than their willingness to share their personal insights and experience with the programmers.

During the preliminary meeting we clarified that they could resign at any time and that we would provide them with transportation and any help that they may require. While the researchers were present at all times to solve any issues raised by the older adults, we also provided them with all our contact details in case they had any questions and doubts before, during, or after the hackathon.

The hackathon took place on March 11 and 12, 2016 (Friday and Saturday), and the researchers made their participatory observations throughout the event. The event started with an opening session on Friday at 7.00 pm, followed by a 24-hour development session. The themes of the hackathon were revealed during the opening session. The participants were told that two topics (tracks) were available in the hackathon–senior’s life and student’s life. There was also an announcement about prizes for the three best teams in each theme. In addition, it was made clear that if the participants wished to pursue the first topic, they would be cooperating with elderly volunteers who had been invited to the event for this purpose (up to two older adults per team). There were no restrictions nor suggestions over the form of cooperation between younger and older participants, since the emergent process was also a subject of the research scrutiny.

The main part of the hackathon was organized as follows. During the development session each team had a separate space i.e. desks and chairs suitable for all team members, including older adults. Each team used their own hardware and software and had free choice of the mobile technology stack. Following the best practices for organizing hackathons there was equal support and number/quality of supplies provided to all of the teams, including food and drinks, network and technical infrastructure (WiFi, electricity), as well as direct tech support from mentors for each technology (IOS and Android respectively).

The hackathon ended on Saturday evening. During the closing session the teams presented their mobile applications in 5 minute demos. Based on these presentation a jury selected the winners. The jury consisted of 15 representatives of various specializations, coming from diverse backgrounds: from academics and NGO activists to IT professionals and business representatives (including a large international mobile carrier and minor mobile software development houses representatives). Each jury member independently proposed their own rank of best apps for each track so the final rank list was the result of combining all of the jury members’ selection lists. The final results on the ranking list left no doubt, as the winning teams’ applications were far ahead of the other ones and the jury unanimously decided to grant them victory.

3.1.2 Participants

In total, 94 younger adults (including both programmers and graphic designers) applied to participate in the hackathon, of which 81 took part in it and formed teams. Altogether 25 teams were formed with up to three programmers and one graphic designer per team. Ultimately, 20 out of the 25 registered teams decided to develop an app in senior’s life track.

Of the older adults invited to the event, 15 decided to participate, which gave a total of 109 registered users with the number of active participants over all age groups reaching 96. The participating older adults were predominantly female (73%), and the mean age of the older adult group was 68 years with a standard deviation of 7.63 years. Most of the older adults were retired and held a college degree.

The group of younger participants consisted of students from different Warsaw universities. In particular, over a half of the participants were PJAIT students. Most of them were second and third year students of computer science, with solid background in programming and mobile technology. Among 9 female participants 8 where students from PJAIT, most of them specialized in graphic design. Detailed information on the younger participants is presented in Table 1.

Table 1 Breakdown of the younger participants

All teams were obliged to have at least one graphic designer. This explains the fact that even though women comprised only about ten percent of the total number of participants nearly a third of the teams had a female participant, mostly in the role of a graphic designer. In the case of the teams with PJAIT students as participants the ratio was even higher – over 50 percent of them had female team members (also students from PJAIT). Moreover eighty percent of teams contained one or more PJAIT students – only five out of the total number of twenty-five teams did not have any PJAIT student onboard. The exact numbers are given in Table 2.

Table 2 Number of teams with a younger adult female participant

In order to anonymize the data and for the ease of future reference, we decided to use a coding protocol, in which we labeled the collected data with the registration number of the older adults and the group name of the younger adults.

3.2 Analysis Tools

As stated in the introductory section, our study objective was to investigate how the participation of older adults would affect the social dynamics in a development team and the general design and quality of the software developed in participatory mode. Because the apps were developed in a competitive context–the hackathon, where the best apps win–the score achieved by each submission can be treated as an external measure of its quality. More subtle methods are needed to evaluate the teams’ performance and the software development process during the event. Based on the aforementioned exploratory context of the study our preferred methods were those involving in-depth observation of the participants, the team dynamics and their individual behaviors. Because the hackathon environment cannot be treated as a controlled experiment, we decided to conduct our research in a case study context combining three qualitative research methods: participatory observation, interviews (group and individual), and surveys.

• 1. Participatory observation: Participatory observation is a qualitative research method that is popular within the social sciences and evaluation fields (Kawulich 2005; DeWalt and DeWalt 2011). In this method, the researcher and his team enter the observed group and participate in its activity. To avoid any interviewer effect, the group is not briefed on the objective of the observation. In the context of software engineering, by focusing on observed behaviors rather than data taken from surveys and interviews, the researcher may gain insights into to the real motives and practices of those being observed. In our study, participatory observation served as a core method for obtaining data in regards to our research objectives. We assigned four field researchers to monitor the hackathon. Each was given a semi-structured observation questionnaire which contained the most important aspects to observe including relations and dynamics inside and outside the teams with regard to intergenerational aspects, verbal and non-verbal communication including seating arrangements and intensity of the interaction. In order to examine the behavior of the groups involved in the event, the observers were asked to interfere as little as possible with the hackathon participants, except in case of potential very significant difficulties i.e. in the communication between the older adults and younger adults. The observations from semistructured questionnaires and the researchers’ individual observation notes were analyzed by the whole team of researchers right after the hackathon in an iterative process based on the affinity diagramming method with active participation of each researcher observing the hackathon.

• 2. Affinity group interviews: Focus group interviews have been successfully applied in software engineering research (Kontio et al. 2008). The affinity group interview is a type of group interview in which the interviewed group comprises of people who know each other, either by formal or informal acquaintance (Hennink 2007). This type of group interview allows the researcher to hear what the interviewees have to say, as well as to track the social dynamics within the group.

  In the context of software engineering, the affinity group interview provides insight into how software solutions evolve within a social context.

  During the course of our research we conducted six affinity group interviews, including one interview before the event and five after the event: one with older adults and four with the teams of programmers.¹ Members of both groups participated in the hackathon. We selected the groups of programmers based on their team’s performance during the hackathon: two teams had participated with the older adult group and won (first and second place), one team had cooperated closely with older adults but failed to win, and one team did not cooperate with the older adults at all. Each interview lasted for approximately 90 minutes.

  For the older adults, we conducted an additional separate group interview prior to the hackathon to address their fears about the event and their role in it. The researchers noted the potential issues that could arise during the hackathon and briefed the older adults on their role within the project.

• 3. Individual interviews: Individual in-depth interviews were used as an auxiliary method to supplement the data collected from the group interviews in order to extract additional insights. In total, we conducted four such interviews with older adults who we noticed to be less active in their focus group, based on our observation of the group dynamics. Therefore, to obtain more in-depth information from them we decided to conduct additional individual interviews as best practices in such cases dictate. During interviews we tried to further explore the vivid topics from the semi-structured observation part of the study which based on various questions from closed-ended, such as How do participants refer to one another? (formal, informal language) to fully open-ended questions such as What is the atmosphere within the group? (very stiff, slightly stiff, rather casual, very casual, friendly, very friendly and so on) which allowed for more descriptive approaches, but gave the option to use a pre-defined scale. In order to obtain more in-depth insight we asked participants after the event about different phases of the process starting from the vision of their role before the event, through idea development process to questions about their perception of cooperation and communication in their team alongside with any inspirations and suggestions to organizers.

• 4. Survey: We used this supplementary tool (Marshall and Rossman 2014) mainly to determine how mutual, declared attitudes of the younger and older generations changed during the course of the hackathon. From studies on stereotypes about the elderly, as presented in Rosencranz and McNevin (1969), we composed a questionnaire with a selection of 12 bipolar adjectives. The results and findings of that tool refer to the contact theory, a widely recognized psychological concept introduced by Allport (1979) and then developed over many years by other researchers, e.g., Pettigrew (1998). According to this theory, the problem of intergroup stereotypes can be addressed by intergroup contact. Although there are several conditions necessary for optimal intergroup contact, many studies have proved that intergroup contact is worthwhile because it typically reduces intergroup prejudices (Pettigrew and Tropp 2006). Based on literature we used two versions of the questionnaire - one used before the event and the second used after the event. Each questionnaire had two blocks of questions. The first addressed general perceptions of the “other” age group (the older adults were asked about young people in general, young people were asked about old people in general) before and after the event respectively. The second block of questions related to a known person who was close to them, but from the opposite age group. Before the event we asked about a familiar person e.g. a family member (i.e., older adults were asked about a young person familiar to them) and after the event the participants were asked about a person from their team (i.e., older adults were asked about a young team member). All participants (juniors and older adults) from the teams that were competing in the “application for older adults” track were asked to complete the survey alongside with appropriate consent to participate in the research. We collected 80 surveys, most of which were complete or partially complete and eight of which were blank (including one team that resigned from the competition). The number of complete answers is presented in Table 3.

  Table 3 Number of non-empty surveys in each part and phase

4 Results and Findings

In this section, we present data that we’ve collected during the case study. Due to the multi-faceted aspects of our analysis tools and the complex nature of the observed event, we decided to describe the results by focusing on each of the defined objectives, rather than providing a linear report of the hackathon event. We divided the results section into two subsections. In the Idea development and app design subsection, we focus on the objectives related to the application design as well as the application quality. In the Social dynamics subsection, we describe the evolution of the interactions between the two generations during the event.

4.1 Social Dynamics

How did the interaction begin? Who took the initiative? After the opening presentations had concluded, matchmaking and team setup ensued. The matchmaking process was unstructured, which led to a disruption in the communication between juniors and older adults. Because the junior participants were mostly students at the Polish-Japanese Institute of Information Technology, they were already familiar with the locations of the designated programming areas in the building. Older adults, however, felt lost and were unable to navigate their way through the building.

In addition, due to space limitations, programming areas had been assigned to the first and third floors of the building, which further hindered older adults’ abilities to keep up with the junior participants. When the older adults finally arrived, they found that the younger participants were already busy setting up their work stations, which increased their feelings of anxiety and isolation. One older adult even stated “They don’t need us here, I reckon” (ID 1, male). During the later affinity group interview, older adults emphasized their disappointment with respect to this stage of the event. When asked to describe the matchmaking process, older adults recalled feeling isolated and deserted by everyone.

When the first group of juniors approached them with their ideas, older adults regarded them as disengaged and disinterested. Some of the older adults stated, humorously, that they felt like slaves at a slave market. They repeatedly emphasized that structuring the matchmaking process would make it much more efficient. The juniors shared the gripes reported by the older adults. The initial chaotic matchmaking phase led to many misunderstandings. In general, the juniors initiated the contact during this phase. We observed that there was only one case in which an older adult took some initiative. This older adult (ID 1, male) arrived at the hackathon with a complete vision for a solution to improve communication between older adults and their friends and family. His attitude was that of a project manager who expected his product to be ready. Apart from the team that contained this particular older adult, only one other team changed its initial plans to pursue goals that were based on its senior member’s ideas and suggestions. Incidentally, these two cases were later to become the two winning teams in the hackathon.

How strong was the collaboration between the two generations? We observed three main types of cooperation between older and younger adults during the event based on the level of cooperation and communication between the two groups. Here we refer to these three types of collaboration as scenarios:

• Scenario 1–Isolation of Older Adults: In this scenario, the programmers made no attempt to make contact with the older adults. After the official opening of the Hackathon, the younger adults went to their designated workplaces and started installing their hardware. Three teams adhered to this scenario. We noted that within these teams there was some discussion about the viability of cooperating with older adults. Some stated that the teams should use the perspective of real older adults because apps developed without inputs from a older adult’s perspective would lead to solutions based purely on negative stereotypes. In contrast, other voices were raised in defense of not cooperating with older adults and insisted that the group participating in the event was not representative, because they already had some experience with ICT.

• Scenario 2–Older Adults as Consultants: Groups that followed this pattern of interaction utilized the help of older adults when designing their hackathon submissions but did not engage in the full interaction we had imagined when designing our hackathon. Rather than inviting the older adults into their groups, the juniors sporadically discussed selected issues with a group of four female older adults (IDs 4, 5, 12, 15) who sat in the corridor outside the designated programming area (actually a makeshift cafeteria for hackathon participants). The general layout of this space is shown in Fig. 1.

  Fig. 1

  

  Plan of the corridor in which the older adults who sat in the cafeteria spent most of their time

  We noted that two of the four sidelined “Scenario 2” older adults were also involved in full-fledged cooperation with another team. This situation was described by all the older adults in the cafeteria as a boost to their self-esteem (“Look at us, we’ve helped three groups already - older adult (ID 12, female)). The older adults also emphasized their belief that they did not need to be present with the juniors, explaining that because the younger participants had obtained the information they needed from them, they could be of no further help by just sitting there in the team room doing nothing. When the junior participants were working at their stations and holding discussions among themselves, the observers noted the same rationalizations being made as those made by the groups that did not make use of the older adults’ help.

  Programmers did not want to treat the insight from older adults with full seriousness, because they deemed their experiences as not representative of the demographic as a whole. The next day when the older adults returned to help with testing, two participants (IDs 12, 4, both female) went to the group of their first choice. Moreover, while little testing was performed, the juniors requested the older adults to help the team prepare the final presentation of their work. In contrast, two senior participants (IDs 5, 15, both female) remained in the corridor. The juniors who had used their opinions during the initial stages of idea development did not return to them for help.

• Scenario 3–Full Cooperation: This scenario includes teams that fully incorporated the older adults into their projects. Older adults played an active role during all stages of app development. We observed full cooperation in five teams. In all these cases the older adults were invited to work together with the juniors at their respective team desks. Figure 2 shows the typical team member seating arrangement around the table. As shown in the figure, we observed three main types of seating arrangements, all of which showed some degree of spatial separation between the two groups.

  Fig. 2

  

  Typical seating arrangements of team members at the tables: “S”–older adults (seniors) and “J”–juniors

How did the attitudes between the generations change during the event?

To answer this question, we used the data collected from the survey. The results, as presented in Figs. 3 and 4, show that the perceptions of both juniors by older adults and older adults by juniors improved on almost every axis. If we treat our groups as random sample of some greater pattern, our results would be mostly statistically significant (see Appendix, Tables 4 and 5)

Fig. 3

Juniors opinion about older adults in general, before and after the event

Fig. 4

Older adults’ opinion about juniors in general, before and after the event

We also analyzed how the cooperative behaviors we observed between younger and older teammates affected their mutual perceptions. We used the label “cafe” for teams that left their older adults in the cafeteria and “coop” for teams that cooperated with their older adults in their main workplace/table. In Figs. 5 and 6, we can see that the differences are marginal. Moreover, in the Fig. 6, we can see that the older adults in the “cafeteria” rated their juniors with even higher scores. This result is reasonable, especially, for survey categories such as independent, decisive, etc.

Fig. 5

Juniors opinions about older adults in own team, based on observation

Fig. 6

Older adults’ opinions about juniors from own team, based on observation

Full results (averages, significance, standard deviations etc.) are presented in Appendix, Tables 4 and 5.

How did the cooperation conclude?

At the end of the programming time, all teams, including the older adults who had waited in the corridor, moved downstairs to the lecture hall where the closing ceremony was to be held. This time both groups arrived simultaneously. When the participants entered the lecture hall, however, older adults and juniors chose separate rows. The younger programmers sat in their teams in a row closer to the podium, whereas the older adults sat together at the back of the hall. Only two of them (ID 12, 14, both female) sat with the teams with whom they had worked. One participant (ID 10, female) sat apart from the group of the other older adults to take pictures. When the submission presentations ensued, none of the juniors making presentations invited the older adults with whom they had worked to join them on stage. In some cases (especially, the teams that had fully cooperated with the older adults), the presenter acknowledged the participation of the older adults. When the programmers arrived at the podium, some of the older adults when speaking with their peers referred to their young team partners as “our boys” or “our team.” During the announcement of the final results, older adult from the winning team (ID 1, male) admitted, “I knew that we would win.”

During the affinity group interview, one week after the hackathon, older adults were asked to recall the names of their teams, the name of the applications they had created, and the names of particular team members. None were able to do so. Only in one case (ID 1, member of the winning team), did any of the older adults referred to their team as “we” or “us.” Unlike the older adults, the younger participants, when asked to recall the names of their senior partners, were mostly able to do so.

4.2 Idea Development and app Design

As planned, the young participants were not briefed in advance regarding the subject of the hackathon; it was a complete surprise, so they could not prepare any ideas for apps a priori. Moreover, the majority had little insight into the needs of older adults. Therefore, the initial phase during which they had to conceive an idea was both difficult and crucial with respect to the final outcome. This phase also involved the first clash between their imagined stereotypes of older adults and the actual older adults sitting with them in their app development team.

How did members of the two generations view their roles in the app development? When discussing their contributions to the team, the older adults exhibited a strong tendency to discount their own input. Some went so far as to state that they feared their suggestions would hinder the juniors’ chances of success. For example, older adults from the team that took second place stated that after the initial idea development stage they were afraid to try and convince the juniors to change their planned submission, as it might mean team failure in the competition. When asked to define their perceived role in the development of apps, the older adults had difficulty coming up with answers. When pressed, most stated that they thought of themselves as consultants rather than team members. In general, the older adults seemed quite dismissive of their own skills and abilities to reach out to the juniors. It is also interesting to note that older adults often considered the problems they encountered in dealing with juniors as a “fact of life.” Many said this is simply how the world works. Younger people will never fully understand the elderly. This was their main reaction to the seeming disinterest they experienced from the juniors. Some of the older adults expressed a feeling of being surprised that they can be viable members of a development team, as one of the stated ’I didn’t think that at our age, we can still be useful.’ (ID 14, female). The juniors, on the other hand, were more positive about the older adults’ performance. In their opinion, the older participants were well integrated as equals in the development process. Moreover, it is interesting that the younger team members were more positive in their evaluations of the skills and contributions of the older adults. Winning teams often emphasized the importance of the older adults’ insights in developing a working application. However, these attitudes were mostly prevalent in the teams that fully cooperated with their senior members.

What aspects of software design were presented to the older adults by juniors? During their interactions, juniors inspired their older partners not only to evaluate ideas for apps but also to talk about their experience with smartphones and tablets and to explain what they were able to do with those devices. Usually, one junior team member would elicit the sharing of the user experience, thus serving as a mediator between the two generational groups. During this phase the focus was mostly made on user experience, on the older adults’ perceptions of the user interface and how the older adults interacted with apps.

What patterns of application development were used by the teams? We note that the development process did not include rapid development practices. Junior programmers were not asked to develop mock-ups or temporary solutions for presentation to the older adults, and the graphic designers did not attempt to create mock interfaces for the older adults to evaluate. Instead, during the first 3 to 4 hours when the older adults were present, all teams that integrated the older participants, were focused mostly on extracting their insight. When the older adults started to leave the event later in the evening, team members exchanged phone numbers and e-mail addresses and made arrangements for the next day of the hackathon. During the night a few older adults reached out to the juniors with their ideas and suggestions. Participant (ID 6, male), a retired chemist, went so far as to e-mail his juniors at midnight and propose an algorithm to use in the app. The next day, from 2 pm onward, the older adults returned to their respective teams. At this stage, the role of their older participants was to evaluate the work done by the programmers.

In all teams this was mostly achieved through presentation. Juniors showed their applications to the older adults, but rarely encouraged them to test. Only in one case (the group with participants ID 6, male and ID 8, female) there was some actual testing performed, which could be partially attributed to the fact that the team’s apps were in different stages of development.

In the team that performed the test, the older participants were presented with a mock-up and asked to try it out. One unique aspect of this team was that the juniors had prepared a structured set of questions to ask the older participants in order to collect useful hints to improve their work. In other teams the testing stage was short, rarely lasting for more than an hour. Typically, the older adults expressed little eagerness to participate in testing, which they justified by saying that they trusted the programming skill of the juniors. As one participant (ID 7, male) put it, Go on with your work boys, I won’t bother you. Surprisingly, the older participants who returned to their teams presented them with small gifts, like a box of chocolates or homemade cake. Some comments they made seemed to suggest that the older adults wanted to compensate for their perceived lack of technical skill by performing some form of parental care for the juniors.

We observed a different approach in teams that had fully cooperated with their older adults. Those teams mostly engaged in active discussion with the older adults, trying to gain information about their needs and visions. As mentioned above, in two teams, these discussions caused the programmers to discard their initial idea and to instead follow the vision of the older adults. Even when juniors followed their own ideas for an app, they included the opinions of the older adults. Active oder adult participation also occurred when it came to naming the products.

What was the role of stereotypes about older adults in app development Stereotypes about members of both age groups played an important role in the process of app development, regardless of the mode of cooperation. However, the type of cooperation employed in each team led to different approaches to those stereotypes. In teams where the juniors did not invite the older adults to participate, stereotypes were used to rationalize that decision. The available older adults were deemed not representative, since they have a grasp on modern technologies while the older adults in general, according to juniors in those teams, are not proficient with ICT. The team within the “cafeteria” scenario (consultant mode) also used stereotypes, primarily as a starting point to test their ideas. Even when the juniors learned that the older adults at the hackathon did know how to use smartphones and tablets, they approached them with the expectation that the older adults were seeing these devices for the first time. This generation gap in knowledge about ICT was also apparent among the older adults who participated in the hackathon, regardless of the mode of cooperation. The older adults would express their awareness of being less skilled in ICT than their younger partners. This awareness was visible in various ways. In some teams it would manifest through expressing doubt about the quality of the input given to the younger adults, in other it would be shown as regret toward suggesting that the younger adults modify or change the idea for their app. In general, self-applied stereotypes proved to be a salient feature of intergenerational interaction. However these stereotypes proved to be the biggest problem in teams with minimal interaction between the two generational groups. A completely different attitude was observed in teams that fully cooperated with their older adults. Although the starting point was a stereotypical view of older adults, continuous interaction led the teams to overcome these biases in creative ways. In response to the concerns voiced by the older adults, the juniors could adapt their vision of an app to meet the needs of older adults. We noted that older adults from the winning teams emphasized the importance of overcoming stereotypes in creating a valuable submission. Another dimension in which stereotypes played a part was the discussion on the need for apps designed for older adults. During the group interview, older adults began to question their special status as a target for ICT solutions. As one of the older adults said, If somebody is smart, and the device is generally easy to use, there is no need for special support for older adults. If someone does not grasp how to use a smartphone, nor does he or she want to, it makes no difference if they are old or young. This suggests the possibility that designs that focused on particular demographics can lead to more societal exclusion rather than promote inclusion.

5 Software Outcomes and Hackathon Follow-Up

Hackathons are brief, intensive forms of software development. Nevertheless, many hackathon participants (and especially, the successful ones) recognize the need of following up their hackathon work (Trainer et al. 2016). This leads not only to ongoing interactions, but also to continued software development, implementation, and sometimes commercialization of the hackathon results. In this section, we describe the follow-up stage of our hackathon, focusing on a description of the software created during the event that continued to be developed afterwards. First, we provide a more thorough description of applications developed by the three teams in which we observed close cooperation between members of the different generations. Then, we briefly describe the remaining applications.

5.1 Super Senior

This winning application was developed with the aim of assisting older adults in their everyday lives. The app consisted of two main components. The first one was a time organizer to help manage the scheduled intake of prescribed drugs as well as social activities. The second component further developed the drug intake aspect. According to the business model proposed by the team members, this app would be linked to a dispenser that would provide the older adult with his/her medication in concordance with the individual’s medical plan. In future work, the authors plan to link this app to pharmacies to automatically inform pharmacists about the need for a refill of a certain medicine for a specific patient, thus making it easier for the patient to access the medicine.

This application, especially the dispenser module, was met with enthusiasm from the head of the senior club organization, who vowed to help the team to contact pharmacies and implement their design. The team continued their work by first designing the 3D model and then preparing the prototype for testing with older adults. They expect to enter the final testing stage right after the summer break (Fig. 7).

Fig. 7

Preview of the Super Senior application

5.2 Tiger: F1

Application F1 came second in the hackathon. This app mostly focused on coordinating a network of volunteers with people willing to exchange help and services. Unlike the app described above, this one had no business model, but was designed for the purpose of improving social cohesion. The authors of the app, inspired by discussions with older adults, focused mostly on modeling a mechanism of trust that would enhance older adults’ feeling of security when asking volunteers or other older adults to help them with their needs. In order to ensure a safe environment, the programmers implemented three main tools of control. First, all volunteers making themselves available to older adults must be endorsed by a reputable institution (schools, charities, churches). Second, each volunteer in the system is given a reputation score, which is made public, and is derived from ratings given to the volunteer by other older adults. Third, when arranging a meeting between a junior and an older adult, both are given a password generated by the system to prevent identity fraud.

The team continued their work in collaboration with older adults from LivingLab and local NGOs in order to prepare the prototype for testing in real life conditions (Figs. 8 and 9).

Fig. 8

Preview of the F1 application

Fig. 9

Preview of the F1 reputation system

5.3 Join

The final app we describe here is the work of a team that didn’t win despite having closely cooperated with their senior members. This app has some similarities with the F1 application described above. It is also based on the exchange of skills and services between younger and older adults. There are two types of user roles, which are based on demographics. The junior role emphasizes physically demanding tasks that can be performed for older adults, while the senior role focuses mostly on sharing experience and insights gathered over their lifetimes. The application is quite minimalistic and is designed mostly for mobile devices.

5.4 Remaining Applications

• Where to pharmacy – An application that notifies older adults of local pharmacies that are offering discounts on medicine,

• ELNERD – a browser designed for older adults, with a voice detection module for mobile platforms,

• Papilot – A tutorial type application that aids older adults with their first experiences with a smartphone; contains an interface with heightened contrast and enlarged fonts,

• Memories Savior – An application that facilitates the storage, retrieval, and exchange of memories between family members,

• i100 – Medicine intake mobile manager

• HoŻy seniorzy (Swift Seniors) – A platform for exchanging information about local events aimed at older adults,

• MemoryCloud – System for creating memoirs,

• Koło rodzinne (The family circle) – A communicator for family members,

• Kolejki (Queues) – A social media platform, that through an exchange of information, appraises older adults on current waiting times at doctors’ offices,

• Babcine Opowieści (Granny’s tales) – Geo-caching application for older adults; allows them to pinpoint a memory in graphical or textual form, to a specific place; later, when reaching the location other users can accesses this memory through their app,

• Blink – A communicator based mostly on exchange of graphics (mostly emoticons),

• Puk Puk (Knock Knock) – Designed to assist older adults in finding help for everyday tasks,

• Album Wspomnień (Memories log) – facilitating the collection and cataloging of photos,

• Silver Tinder – Imitates the swapping mechanism from Tinder; a platform for meeting new people in the local area,

• Mobile Tigers – Medicine intake organizer

• Silent Disco – Allows younger people to hold silent disco parties that would not disturb elderly neighbors.

6 Conclusions and Recommendations

In our case study we wanted to analyze how the inclusion of older adults in development teams would affect team performance. We were interested in the social effects of such cooperation, as well as how it would affect software development. In order to measure these effects, we have used an array of both qualitative and quantitative research tools. Within the hackathon setting, we have created favorable conditions for cooperation of developers and older adults. However, we allowed developers and older adults alike to make autonomous choices regarding their mutual cooperation.

In particular, we have pursued two broad research objectives:

• 1. Observe the dynamics of social interaction within the development teams between older adults and junior developers

• 2. Explore the extent to which participation of older adults affects the development process and verify the participatory design approach

6.1 Conclusions from Observation of Social Interactions Between Older Adults and Junior Developers

Older adult–developer interaction scenarios. The most important findings from our study concern the use of three kinds of typical interaction scenarios that differ in their involvement of older adults. These are:

• 1. Isolation of Older Adults: no involvement of older adults, use of stereotypes by developers

• 2. Older Adults as Consultants: ad-hoc involvement of older adults in various projects

• 3. Full Cooperation: comprehensive involvement of older adults in idea generation, as well as evaluation stage of a project.

These findings are an important addition to the current knowledge as they show the typical autonomous choices of developers faced with the challenge of designing software for older adults. Our findings can probably be generalized to settings other than hackathons. Compared to previous research that advocates the use of the participatory design approach and direct involvement of older adults, our findings demonstrate the gap between theory and practice: many developers chose the “Isolation” scenario, even though older adults were available on site and could be involved in the development process. On the other hand, many older adults chose the “Consultant” scenario, instead of becoming fully involved in a project. Both of these choices are caused by different mental barriers of developers and older adults, respectively. In the case of developers, the barrier is caused by a tendency to use stereotypes. In the case of older adults, the barrier is mostly caused by a lack of sufficient self-esteem.

To summarize: our findings demonstrate that even in favorable conditions for cooperation of software developers and older adults, the “Full Cooperation” scenario - most favorable from the point of view of participatory design theory - is not always chosen. Either of the two sides can decide to not cooperate fully with the other, resulting in the “Isolation” or “Consultant” scenarios.

Role of stereotypes and attitude change

We have observed the role of stereotypes and attitude changes of hackathon participants. Stereotypes are responsible for decisions of some developers not to involve older adults fully in the development process. On the positive side, our findings clearly demonstrate that direct interaction reduces negative stereotypes and improves positive intergenerational attitudes. In this aspect, our study confirms the results of related work in an enterprize setting (Schloegel et al. 2016). Although stereotypes are often a negative influence in the social context, they can be a useful starting point for consideration when designing an application. Teams that could discuss the social perceptions of the elderly with their older adult members were able to overcome the negative older adult’s stereotypes and creatively address problems related to the lives of older adults.

6.2 Conclusions About Effect of Participation of Older Adults on the Development Process

Previous research has shown that direct involvement of older adults in design process in participatory mode is a low-cost approach that facilitates the process of software development, in particular the development of mobile applications. Our research mostly confirms the positive effect of direct involvement on applications developed in the hackathon. However, we have observed several factors that affect the involvement of older adults. Generally speaking, it is not enough to just invite older adults to participate and be physically present during the software design process. The most important discovered factors that affect participation of older adults in the development process are:

• 1. Initial rapport. When designing an intergenerational software development project, it is crucial to establish a rapport between the participants. During our hackathon, the teams that overcame their initial resistance experienced during the matchmaking phase were able to create formulas for full and fruitful cooperation. Recent research suggests that the use of brainstorming may be an effective method to improve initial rapport of older adults and developers (Filippova et al. 2017).

• 2. Older adults’ self-esteem. Self-esteem is a critical aspect in working effectively with older adults. Our case study showed older adults to have a rather negative view of their own achievements and potential to contribute to the team, resulting in their decision to use the “Consultant” rather than the “Full Cooperation” scenario. When inviting older adults to participate in development teams, it is important to address this issue. Self-esteem is also significant during the tesing stage, when older adults need to be encouraged to participate in testing.

• 3. Collaborative motivation. Despite their self-esteem issues, older adults displayed interest in participating in the development process. Unlike younger participants, the older adults were less competitively driven and more fair and kind in their interactions. This may suggest that better development results may be obtained when older adults are made to understand that the success of software development results depends on their involvement, and that the developed software can have a positive social effect.

Apart from identifying new factors that affect the participation of older adults in the development process, we have found a clear effect of the collaboration scenario on the software quality. The hackathon teams that used the “Full Cooperation” scenario were the most successful. This finding supports the theory of participatory design, when applied to applications for older adults. The downside is that the “Full Cooperation” scenario is not always autonomously chosen by developers or elders. Both sides need guidance or external motivation to overcome mental barriers against full cooperation.

6.3 Recommendations Concerning Hackathon Organization Involving Older Adults

Based on the observations we made during this case study, below we identify some good practices that will enhance the quality of hackathons in which older adults are involved.

• Mind the space: When making plans for a hackathon to which older adults will be invited to participate, it is important to carefully consider the location. The organizers should choose a location familiar to the participating older adults. If no such a place is available, a location with a simple room layout is best. If possible, the hackathon should take place entirely on one floor (preferably, the first or ground floor) to minimize confusion and the physical effort required to participate. This observation has not been made so far in previous work, as few or no hackathons have involved older adults.

• Keep them in touch: When inter-generational cooperation is important, the first few hours of an event are critical in setting the tone and making participants feel welcomed when matchmaking occurs. Both junior and older adults participants must not be left to their own devices without any guidance. When this occurs, junior participants retreat to set up their work stations, while the older adults feel left out. To combat this outcome, the organizers should encourage communication from the very start, i.e., through pre-hackathon discussions and sessions to build rapport between the age groups. This finding confirms previous research about hackathon organization.

• Take into account different collaboration strategies: Our initial assumption that each older adult would work closely with only one team turned out to be only partially correct. Some noncompetitive older adults were ready to help all the teams. Many of the younger developers, for their part, expected only short, infrequent sessions with the older adults to verify a design or idea. Therefore, it is worthwhile to create the opportunity for both participation strategies and/or to make it possible for older adults to drift from one type of collaboration to another. Because our study is the first to report different cooperation scenarios chosen spontaneously by developers and older adults who work together, this is a new recommendation for organizing hackathons.

• Encourage user involvement: Technical aptitude, while necessary for creating a working prototype, is not a useful criteria when planning to build functional intergenerational teams. Too much focus on purely technical aspects can lead to greater feelings of isolation by older adults who are not skilled in this field. Therefore, supervision and mentoring with respect to the participatory design process and optimizing user experience is an important consideration for event organizers. For older adults participants who are skilled technicians (i.e., retired programmers or engineers), this is a good practice and may not be as critical as for those not from the field. Discretion is advised.

• Change typical hackathon schedule and scope: While we have conducted a hackathon with typical duration (2 days and a night) and scope (full development process), we would advise future organizers of hackathons that involve older adults to consider changing schedule or scope (or both). In order to facilitate full participation of older adults we should start the hackathon earlier and perhaps we should organize it in shorter form of a one-day event. If the hackathon duration is shortened, the scope can be changed to a selected part of design cycle, namely the design stage in order to obtain better prototypes even without any code (encouraging the use of live mockups).

6.4 Study Limitations

Our case study has been carried out at a university in Poland. This may limit the studies’ findings to a particular culture and community. This limitation may be alleviated by the fact that most participants where students of Informatics or Computer Science faculties that have a fluent grasp of the English language and a greater familiarity of contemporary global culture.

The choice of a hackathon for the case study may limit our findings because hackathons have several special characteristics (Trainer et al. 2016). Firstly, a hackathon is influenced by its community and topic. This implies that the conclusions of our research may not apply in commercial environments or in the case when the topic would be change for example to medical software for older adults (which would require involvement of medical experts).

Secondly, a hackathon imposes limitations on performance of software teams (Trainer et al. 2016). Within the context of a Hackathon, performance is often sacrificed for team building, and establishing interpersonal connections. The time constraint further enforces this effect. What is more, state of the art in the field of diversity studies in IT settings also suggests that diverse Hackathon teams suffer from lower performance. However, the focus of our research is not on team performance or on the quality of the final product of the teams’ work. Our main focus was put on the initial stages of idea development, when two groups would interact the most, and agree upon the general outline of the solution they want to deliver. This process has been observed for 25 diverse teams involved in our case study.

7 Future Work

Our case study results open a plethora of further questions. First, our observations might be generalizable to most developed countries in the European cultural circle, but mperhaps not worldwide. It would be particularly interesting to conduct similar studies in Asia and South America. In upcoming months, we are considering to organize a similar event abroad in cooperation with one of our partners.

Some questions can only be answered after a careful study in a controlled environment. As such, we plan to conduct three workshops with older adults that will address three crucial aspect of the software production cycle: testing, design, defining requirements, and ordering product. In each workshop, its participants will be confronted with actual problems and asked to solve them within a given budget. We will observe which strategies are adopted by older adults and how they work.

Another future research direction is on the effect that such events have on the mutual perceptions of members of different generations. To test their effect, we will conduct a study comparing this hackathon with a location-based games setup (Kopeć et al. 2017). We will also monitor the development and use of the applications presented during this event. As this text is being prepared, at least one of the winning applications is expected to be implemented in the community.

Appendix

Table 4 Averages of survey results

Table 5 Standard Deviations of survey results