Ecological Sustainability in Software Development: The Case of a Technical Consultancy Firm

(1)

IN THE FIELD OF TECHNOLOGY DEGREE PROJECT

INFORMATION AND COMMUNICATION TECHNOLOGY AND THE MAIN FIELD OF STUDY

INDUSTRIAL MANAGEMENT, SECOND CYCLE, 30 CREDITS

,

STOCKHOLM SWEDEN 2021

Ecological Sustainability in

Software Development

The Case of a Technical Consultancy Firm

(2)

(3)

Ecological Sustainability in Software

Development

The Case of a Technical Consultancy Firm

by

Bercis Arslan

Master of Science Thesis TRITA-ITM-EX 2021:183 KTH Industrial Engineering and Management

(4)

Ekologisk Hållbarhet inom

Mjukvaruutveckling

En Fallstudie inom ett Teknikkonsultbolag

av

Bercis Arslan

Examensarbete TRITA-ITM-EX 2021:183 KTH Industriell teknik och management

(5)

Master of Science Thesis TRITA-ITM-EX 2021:183

Ecological Sustainability in Software Development Bercis Arslan Approved 2021-06-08 Examiner Matti Kaulio Supervisor Gisela Bäcklander Commissioner Knightec AB Contact person Sara Vickman Abstract

Sustainability in the software and Information Technology (IT) industry has previously been discussed by practitioners mostly with a focus on maintainability and extensibility. In turn, the ecological and environmental dimensions of sustainability have been neglected.

Previous research has shown that there are obstacles in the industry in terms of knowledge, experience, and support. Lack of knowledge stems from a lack of tools to detect and determine factors that affect environmental sustainability in software development, such as energy consumption. Furthermore, examining employees’ motivations, attitudes, and discretionary behaviours is important to understand how implementation can be enabled and sustained.

The purpose of this study is to find practices and tools for achieving environmental sustainability in software development as well as understanding what factors are hindering software engineers from adopting sustainable practices and tools that already exist.

A qualitative single case study was conducted with semi-structured interviews as the primary method for data collection. The interviews were performed with individuals with various roles within software engineering as well as their managers.

The findings show that the focus on environmental sustainability in software development is insufficient as for now. Practices, such as, reduction of CPU cycles and inactivating idle programs are suggested as environmentally friendly. Additionally, the findings display hinders in areas such as responsibility, requirements, and knowledge. Organizations and their stakeholders have to prioritize and work against these hindrances in order to succeed with environmental efforts.

Keywords: Sustainability, Software Development, Sustainable Software Engineering, Energy Consumption, Cloud Computing

(6)

Examensarbete TRITA-ITM-EX 2021:183

Ekologisk Hållbarhet inom Mjukvaruutveckling

Bercis Arslan Godkänt 2021-06-08 Examinator Matti Kaulio Handledare Gisela Bäcklander Uppdragsgivare Knightec AB Kontaktperson Sara Vickman Sammanfattning

Hållbarhet inom mjukvaru- och Informationsteknologi (IT) -industrin har tidigare diskuterats av utövare mestadels med ett fokus på underhållning och tillbyggnad av mjukvara. Den ekologiska och miljömässiga hållbarheten har därför blivit försummad. Tidigare forskning har påvisat att det finns hinder i industrin gällande kunskap, erfarenhet, och stöd. Brist på kunskap härrör från en brist på verktyg för att upptäcka och fastställa faktorer som påverkar miljömässig hållbarhet inom mjukvaruutveckling, så som energiförbrukning. Dessutom, att undersöka de anställdas motivationer, attityder, och beteende är viktigt för att förstå hur en implementation kan möjliggöras samt upprätthållas.

Syftet med denna studie är att hitta praktiker och verktyg för att uppnå miljömässig hållbarhet inom mjukvaruutveckling samt att förstå vilka faktorer som hindrar mjukvaruutvecklare att uppta hållbara principer och verktyg som redan existerar. Studien är genomfört som en kvalitativ fallstudie med semistrukturerade intervjuer som primär metod för datainsamling. Intervjuerna var genomförda med individer inom olika roller för mjukvaruutveckling samt deras chefer.

Resultatet visar på att det finns ett otillräckligt fokus på miljömässig hållbarhet inom mjukvaruutveckling för tillfället. Praktiker så som reduktion av CPU cykler och inaktivering av program på tomgång (idle programs) är antydda att vara hållbara ur ett miljöperspektiv. Dessutom visar resultatet på att det finns hinder inom områden så som ansvar, krav, och kunskap. Organisationer och deras intressenter behöver prioritera och arbeta mot dessa hinder för att lyckas med miljömässiga insatser.

Nyckelord: Hållbarhet, Mjukvaruutveckling, Hållbar Programutveckling, Energikonsumtion, Molntjänster

(7)

List of Figures

1 SaaS, PaaS, and IaaS (Klochkova 2015) . . . 11

2 The SDLC (Pinheiro 2018) . . . 13

3 Process Enhancements for Sustainable Software Engineering

(Dick et al. 2013) . . . 15

(10)

List of Tables

1 Here, the disposition of the thesis is presented. A short

de-scription is given of the contents of the chapters. . . 5

2 Overview of the conducted interviews . . . 24

3 Measures and classification of energy consumption (Oyedeji

et al. 2018). . . 67

(11)

Acronyms

AWS Amazon Web Services. 22, 33, 40 CPU Central Processing Unit. 8, 32, 46, 54 IaaS Infrastructure as a Service. 10, 11, 48

ICT Information and Communication Technology. 1, 2, 7 IT Information Technology. 1, 2, 4, 7, 8, 10, 13, 15, 17, 43 PaaS Platform as a Service. 10, 48

SaaS Software as a Service. 10, 11, 48

SDLC Software Development Life Cycle. 12, 13, 15 SE4S Software Engineering for Sustainability. 7

(12)

Acknowledgements

This section is dedicated to everyone who has helped or supported me during the writing of this thesis. First and foremost, I would like to thank Knightec AB for guidance throughout the process and being given the opportunity to research on such an interesting topic. A special thanks to my corporate supervisor Sara Vickman for her willingness to help and in gaining valuable

connections. Secondly, I would like to thank my supervisor Gisela B¨acklander

at KTH for her experience and knowledge. Without her feedback, the out-come of this thesis would not have been at this level. Additionally, I am grateful for all individuals who took their time to partake in this study’s interviews. Finally, I would like to give a warm thank you to my family, Zumrut, Ceyhun, and Nergiz, for their constant love and support. Their encouragement means the world to me.

Bercis Arslan

(13)

1 Introduction

This chapter presents the background of this thesis. The background is fol-lowed by the problem formulation, purpose, research question, and delimita-tions of this report. Lastly, the outline is presented.

1.1 Background

Climate change is continuously affecting people and the planet. To mitigate our environmental impact, the topic of sustainability has become increasingly important not only for the general public but for the business world as well (Maryville 2019). The most popular definition of sustainable development is given in the Brundtland report (United Nations World Commission on Environment and Development 1987) which states:

Sustainable development is the development that meets the needs of the present without compromising the ability of future genera-tions to meet their own needs.

There exist three dimensions of sustainability, often named ”the three pillars of sustainability” (Purvis et al. 2019). These dimensions are identi-fied as economic development, social development, and lastly, environmental protection. Firms that fail to prioritize sustainable development often receive criticism and lose market legitimacy, therefore, many industries are trying to take responsibility for their ecological footprint (Du et al. 2013). Sustainabil-ity in the software and Information Technology (IT) industry has previously been discussed by practitioners mostly with a focus on maintainability and extensibility. In turn, the ecological and environmental perspectives of sus-tainability have been neglected (Groher & Weinreich 2017). Organizational and economical aspects of sustainability are often prioritized, leaving envi-ronmental considerations absent.

Sustainability in software development is a double-edged sword. Software solutions, now and in the future, will be critical for the environment through solutions in energy, manufacturing, agriculture, transportation, and much more (Infotech 2021). These will be vital in terms of for example tackling deforestation and reduce emissions. However, software is also a part of a

rapidly growing carbon footprint (Podder et al. 2020). The Information

(14)

of total global greenhouse gas emissions. However, ICT solutions have the potential to reduce the emission rate by 15% (Muthu et al. 2019).

Not only is the sector as a whole contributing to climate change, but there are also examples of specific software solutions, even with the intent to solve environmental issues, surprisingly doing the opposite through its indirect effects. An example is blockchain networks for micro-grids used to trade energy between residents, which required more energy than the nation of Switzerland to maintain the system (Podder et al. 2020).

There are also examples of solutions with considerable advantages that are being overlooked in terms of their energy consumption, such as cloud technology, which plays a major role in the IT industry. Moving to cloud technology serves multiple benefits such as the optimization of hardware resources and cost-efficiency (Oliviera 2015). Even though cloud technology is a great solution in many ways, it consumes substantial amounts of energy leading to significant levels of carbon emissions (Zakarya & Gillam 2017). In 2014, in the US only, cloud computing consumed 70 billion kWh of the US total energy consumption equaling 1.8% (Zakarya & Gillam 2017). Due to the increased number of computational resources, energy costs are one of the highest expenses of cloud service providers.

With that said, firms who can integrate software sustainability early on in the design process are more likely to take account of environmental impacts, as leaving such considerations for later tends to be very expensive (Kramer 2012, Dick et al. 2013). Assessing the environmental impacts through stan-dardized techniques such as calculating the carbon footprint, or conducting life cycle assessments are complex and sometimes even performed after the product is on the market (Acaroglu 2018). Investigating the sustainabil-ity impact of daily activities during the development phase of software may therefore lead to a more effective approach for reduced environmental impact.

1.2 Problem Formulation

The software and IT industries are trying to keep up with new demands on sustainable businesses but seem to have a narrow view of sustainability as the focus mostly lies on technical qualities followed by economical and organizational concerns (Groher & Weinreich 2017, Chitchyan et al. 2016). Consequently, the environmental considerations are mostly absent but are nonetheless equally as important as other sustainability aspects. Moreover, people are more and more interested in businesses that reflect their values,

(15)

not only through sustainable end-products but also through ensuring that the way of working is environmentally sustainable (Infotech 2021).

Previous research has shown that there are obstacles in the industry in terms of knowledge, experience, and support on an individual, as well as professional level and that norms and practices have to be reformed to pro-mote sustainable outcomes (Chitchyan et al. 2016). Practitioners are not as successful at developing green applications as they could be due to a lack of information and support infrastructure (Manotas et al. 2016). According to Pinto & Castor (2017), the lack of knowledge stems from the lack of tools for software developers to detect and determine the energy consumption of the products they develop. Further research is needed on how barriers to adoption and implementation of sustainable development tools and practices can be overcome.

Additionally, Matos Clegg (2013) state that it is more likely for organiza-tional change to occur if the topic of sustainability naturally emerges rather than it being imposed onto the employees, meaning that the employees them-selves initiate directive. Examining employees’ motivations, attitudes, and discretionary behaviors in relation to sustainability therefore seems impor-tant to understand how implementation can be enabled and sustained.

1.3 Purpose

The purpose and aim of this study are to find practices and tools for achiev-ing ecological sustainability in software development and maintenance. Fur-thermore, the purpose is to understand what current factors are hindering software engineers from adopting practices and tools that already exist, both on an individual level as well as in the organization as a whole. The or-ganization in the study is in this case a technical consulting firm based in Sweden.

1.4 Research Questions

The research questions formulated to fulfill the purpose of this thesis are: • What practices and tools can be incorporated during software

develop-ment and software maintenance for a reduced ecological footprint of software?

(16)

• What factors are hindering the acceptance and adoption of environmen-tally positive practices and tools in software engineers in the case of a technical consulting company?

1.5 Delimitations

This study only considers the environmental and ecological aspects of sus-tainable development, with a focus on practices and tools during all parts of the software development process, including maintenance. Technical sustain-ability such as the longevity of the product is not considered. Furthermore, the focus is on investigating what changes can be made within the processes of software engineering and development, to make it green and ecologically sustainable. The practices are many and therefore, limited to ones that are ”closest” to the programmer, such as, coding practices. Those are believed to be easiest to incorporate into the daily work of the developer and therefore be more impactful.

The scope is further limited to the mid-sized Swedish technical and IT consulting firms as the case covers this particular context. The interviewees are a part of one business unit within the company, and results are based on their views. However, the findings may be significant for any industry, firm, or individual that develops code and software systems, as the way of working might be similar. What should be noted is that the perception of sustainability and the urgency of adoption of sustainable practices might differ between company cultures and countries (Yttredal & Homlong 2020).

(17)

1.6 Outline

Table 1: Here, the disposition of the thesis is presented. A short description is given of the contents of the chapters.

Chapter Chapter Description

1. Introduction

Presents the background to the problem formulation, the purpose, as well as the research questions. Thereafter, the delimitations are introduced.

2. Literature Review

Presents the literature review, including definitions of sustainable software development, and how it is measured. Thereafter, a description of known problems and solutions regarding energy efficiency is given, followed by an overview of cloud technology and the traditional processes

in software development. Lastly, organizational and professional barriers are presented.

3. Methodology

Presents the methodology of this study. It begins by describing the research design and the research process. Following, a presentation of the methods for data collection and data analysis. Lastly, an assessment of the research quality is given and a discussion of research ethics.

4. Findings and Analysis

Presents the findings of this study. The results are divided into three areas, energy consumption, organizational barriers and enablers, and professional barriers and enablers.

5. Discussion

Interprets the findings from previous chapters and discusses them together with prior literature. The chapter is structured based on themes identified during data analysis.

6. Conclusion

Presents the conclusion of this study. Main findings are summarized. Additionally, practical and theoretical implications are discussed. Lastly, limitations and future research are presented.

(18)

2 Literature Review

This chapter presents the literature review including theories, concepts, and previous research related to the problem statement. First, a general overview is given in section 2.1 of sustainable software engineering and its different definitions. Section 2.2 focuses on energy efficiency including a review of known problems and solutions. Section 2.2.3 introduces cloud technology and its role in sustainable software development. Section 2.3 presents traditional working methods in software development and how those can be adapted for increased environmental sustainability. Lastly, the enablers and barriers of adoption of sustainable practices are discussed in 2.4.

2.1 Sustainable Software Engineering

One of the most popular and well-known definitions of sustainable develop-ment is the one develop-mentioned in the Brundtland report (United Nations World Commission on Environment and Development 1987) as ”the ability to meet the needs of the present without compromising the ability of future genera-tions to meet their own needs”. This also encompasses a long-term balance in social, economic, and environmental objectives. As for environmental sus-tainability specifically within software engineering, various definitions exist (Brooks 2020, Muthu et al. 2019, Naumann et al. 2011, Dick et al. 2010).

Definition 1. Green and Sustainable Software is software, whose di-rect and indidi-rect negative impacts on the economy, society, human be-ings, and environment that result from development, deployment, and usage of the software are minimal and/or which has a positive effect on sustainable development (Dick et al. 2010).

However, according to (Naumann et al. 2011) the first definition of sus-tainable software only considers the organizational responsibility and aware-ness of negative and positive impacts of the actual product and not the impacts during the development process. Therefore, Naumann et al. (2011) developed a second definition that expresses those concerns as well.

Definition 2. Green and Sustainable Software Engineering is the skill of creating green and sustainable software (as per definition 1) through green and sustainable software engineering process. It is the art of defining and developing a product in a way so that the positive and

(19)

negative impacts of sustainable development are continuously assessed throughout the software development life cycle (Naumann et al. 2011). A third, more general definition has also been developed.

Definition 3. Software Engineering for Sustainability (SE4S) is ac-cording to Brooks (2020), Muthu et al. (2019), and Penzenstadler (2014) supporting all dimensions of sustainability throughout the soft-ware life cycle with a primary focus on environmental sustainability. Through requirements engineering and quality assurance, the develop-ment and progress of sustainable developdevelop-ment can be assessed.

The second definition ”Green and Sustainable Software Engineering” con-siders both the software itself as well as the whole engineering process. In this thesis, I examine both how practices affect the product and how tools and practices themselves may contribute to sustainability. Therefore, this is the definition of sustainable software development that I use in this thesis.

2.1.1 Impacts, Measures, and Metrics

According to Berkhout & Hertin (2001), negative environmental impacts of ICT can be divided into first-, second-, and third-order effects.

The first-order effects are described as direct environmental effects due to the production, use, and disposal of hardware, devices, and other compo-nents.

The second-order effects are indirect environmental effects such as the incomplete substitution of existing activities, meaning that ICTs did not replace existing systems but supplemented them, thus leading to more envi-ronmental damage. An example of an incomplete substitution could be the strive for a ”paperless office”. The use of computers in business administra-tion has not fully replaced tradiadministra-tional paperwork, it only supplemented it, therefore, the ”paperless office” never occurred. This in turn has led to addi-tional environmental damage, not only from producing and using paper as a resource but from manufacturing and energy consumption of the computers. Third-order effects relate to structural changes in the economy due to the birth, survival, and death of IT firms. Third-order effects occur when demand increases of ICT related services and products to a point to where it either balances out or overcompensates for the positive environmental effects that ICT solutions bring, much like the rebound effect (Grubb 1990).

(20)

Energy efficiency (measured in Joule) and power consumption (measured in Watt) are two of the few measures for evaluating whether the software is environmentally sustainable or not (Oyedeji et al. 2018, Ardito et al. 2015), since those are the primary resources used by hardware to run the software (Beghoura et al. 2017). The relationship between energy (E) and power (P) over time (t) is stated by the equation E = P ∗ t (Pinto & Castor 2017). A common misconception regarding time in the aforementioned formula is that the reduction of execution time would always reduce energy consumption, which is not the case. The reduction of time may result in an increase in Central Processing Unit (CPU) cycles through the use of multi-core CPUs and in turn, increase the P of the equation (Pinto & Castor 2017).

Oyedeji et al. (2018) have compiled some ways in which energy efficiency and power consumption can be classified. One example is the ”software energy cost” which is defined as the computational cost of performing a task (including CPU processing, memory access, I/O operations, and more). Another example is ”Power usage effectiveness” defined as the total facility

energy divided by IT equipment energy. Johann et al. (2012) described

energy efficiency as ”Useful Work Done” divided by ”Used Energy”. All these formulas are preferably used early on in the software development process for continuous assessment of the environmental impacts. Detailed information regarding these formulas can be found in Table 3 in Appendix A.

2.2 Energy Consumption

Since the few measurements for green and sustainable software are energy and power consumption (Oyedeji et al. 2018, Ardito et al. 2015), already known problems and solutions related to this will be discussed in a section of its own. Below, previous research regarding energy-related practices and energy-related tools for green and sustainable software is presented. The energy-related practices are many and therefore, the study has been limited to discuss practices that are ”closest” to the programmer, such as coding practices, as those can easily be incorporated into the daily work.

2.2.1 Energy Related Practices

There are several coding practices for reducing energy consumption (Geor-giou et al. 2019, Pinto & Castor 2017, Li & Halfond 2014, Sahin et al. 2014). Georgiou et al. (2019) compiled coding practices that have been shown to

(21)

re-duce energy consumption. Examples of such practices are putting processes and threads to sleep when they are inactive, or have not received an I/O operation, using efficient queries (avoid indexing or ordering when unneces-sary), and replacing macros with function calls to reduce the number of lines of code in the program.

For Android smartphone applications specifically, avoiding references to array length by initializing a variable with the length first, was shown to reduce energy consumption by 10 % (Li & Halfond 2014). Furthermore, direct access to object fields reduced energy consumption by 35 % for reading field values, and 31 % for setting field values. This means that developers should directly access objects rather than through a method if they are trying to save energy (Li & Halfond 2014).

Refactoring, which is the process of restructuring code often done in the maintenance part of the Software Development Life Cycle (SDLC) (see sec-tion 2.3), has been shown to have an impact on energy usage by applica-tions (Pinto & Castor 2017). Sahin et al. (2014) found that, even though refactoring affects energy usage, it is consistent neither within nor across ap-plications, nor within or across platforms, meaning that, refactoring can in some cases increase energy usage or decrease energy usage from time to time. Out of all refactoring practices tested, extracting a local variable (creating a new variable and replace the reference to the new variable) was the only implementation that consistently decreased energy consumption (Sahin et al. 2014).

2.2.2 Energy Related Tools

Various tools can also support the evaluation of energy efficiency. These can be further divided into software-based and hardware-based tools, as sug-gested by Georgiou et al. (2019). Hardware-related monitoring tools, com-pared to software-related monitoring tools, cannot, in most cases, work as stand-alone systems as they require additional hardware components to func-tion. Therefore, measuring energy efficiency through hardware-based tools can be more demanding than its counterpart (Georgiou et al. 2019).

Some software-based tools include algorithms such as the random forest algorithm used to detect energy-consuming portions of code (Beghoura et al. 2017), energy optimization algorithms in distributed applications (Kwon 2013), or programs based on the existing Android Toolkit, for example, ”PETrA” for measuring the energy consumption of Android applications

(22)

(Di Nucci et al. 2017). ”PETrA” stands for Power Estimation Tool for An-droid and is able through publicly available Project Volta (project initiated by Google to tackle issues regarding battery life of Android smartphones) API’s, measure energy consumption. It is compatible with Android devices equipped with Android 5.0 or higher (Di Nucci et al. 2017).

Examples of hardware-based tools for measuring energy consumption in-clude ”Atom LEAP”, for characterizing energy usage at the level of task com-putation and operating system, (Singh & Kaiser 2010) and ”GreenMiner”, measuring the energy consumption of mobile devices through the collection of software performance data (Hindle et al. 2014).

2.2.3 Cloud Technology

Cloud technology or cloud computing is one of the major areas that the studied business unit is specialized in. Therefore, it is relevant to present the state-of-the-art research regarding aspects that touch ecological sustainabil-ity in software development such as resource optimization, profitabilsustainabil-ity, and green cloud computing. These topics are of interest because resource man-agement in terms of energy is a part of the assumption on how ecological sustainability in software development can be achieved.

Cloud computing is a fairly new model for consumption and delivery of IT services as it provides dynamically scalable and often virtualized resources over the internet. Cloud computing is an umbrella term for multiple services such as data processing, data storage, or software accessible from external server halls connected via the internet.

The three core services cloud computing offers are: (1) Software as a Service (SaaS), (2) Platform as a Service (PaaS), and (3) Infrastructure as a Service (IaaS). As illustrated in Figure 1, they have different properties, advantages, and disadvantages. SaaS software is available via a third party over the internet and is at the highest level in the hierarchy. SaaS software is owned by the vendor and runs on their data centers. In this model, the user does not have control over the underlying cloud infrastructure. More-over, SaaS applications do not require any downloads or installations on the client-side. Example of popular SaaS products include Microsoft Office 365, Salesforce, and LinkedIn. PaaS are based on an IaaS service where the con-sumer is solely responsible for the software and data whereas the servers, storage, and networking are maintained automatically by the enterprise or a third-party provider. The platform layer consist of operating systems and

(23)

application frameworks (Jing et al. 2013). Two examples of PaaS products are MySQL and Microsoft SQL. The IaaS layer is responsible for managing the physical machines, creating a pool of virtual computation, and provid-ing an elastic resource service to the upper layer (Jprovid-ing et al. 2013). IaaS is completely handled by the consumer in terms of accessing and monitor-ing computation, networkmonitor-ing, and storage and allows consumers to purchase resources on-demand instead of investing in hardware (Chapel 2019). Ulti-mately, the different services provide the user with various amount of control of the system where SaaS provides the least amount of control and IaaS the most. Popular IaaS products include Amazon Web Services (AWS) and Microsoft Azure.

Figure 1: SaaS, PaaS, and IaaS (Klochkova 2015)

The ultimate goal of cloud computing is to reduce costs, dynamically utilize resources, as well as maintain resources in favor of the consumer (Ra-manathan & Latha 2014). A large number of resources (the resource pool) are shared among the cloud consumers through virtualization technology. Companies can rent resources from cloud providers for storage and compu-tational purposes to reduce their own infrastructure costs (Vinothina et al. 2012). From the consumers’ perspective, for example, a consulting firm, the job should be completed in time with the minimum amount of resources in turn minimizing costs due to the subscription-based pay-as-you-go busi-ness model (Li et al. 2017). Resource allocation is the process of assigning available resources to the needed cloud applications over the internet. In

(24)

Vinothina et al. (2012), they explain that the current challenges regarding resource allocation for the cloud providers are meeting customer demand and application requirements as well as minimizing costs associated with resource allocation. According to Li et al. (2017), the cloud providers need to compute optimal resource allocation to maximize their own benefit whilst minimizing the cost of energy consumption for providing virtual machines.

Unfortunately, previous research has not investigated the relationship be-tween resource management in cloud computing and software sustainability. However, there has been some research made on the topic of green cloud com-puting. Green cloud computing research considers how different techniques and infrastructure designs affect the energy consumption of servers within cloud computing systems as investigated by for example, Gill et al. (2019) and Xie et al. (2013). As green cloud computing is out of the scope of this thesis, it will not be investigated further.

2.3 Software Development Life Cycle

To understand how one can adapt practices for sustainable software devel-opment, one has to first be informed about the traditional practices.

In software engineering, the software development process Software De-velopment Life Cycle (SDLC), is the process of dividing software deDe-velopment into a set of activities to improve design, product management, or project management (Kuhrmann et al. 2017). SDLC can also be described as a sys-tematic approach to create software of high quality and at the same time minimize risks and failure (Bhatnagar 2015). The division of activities can be made in multiple ways depending on the size of the project, product pro-file, competition field, and more (Dima & Maassen 2018). Therefore, various models exist, some of which are further described below. Generally, it can be viewed as six different phases as illustrated in Figure 2, consisting of plan-ning, analysis, design, implementation, testing and integration, and lastly maintenance (Bhatnagar 2015).

A brief description of each stage is given below according to Pinheiro (2018).

1. Planning and Analysis: Stakeholders and project managers discuss requirements of the product, implementation strategies, and tasks. 2. Design: A design is prepared based on the requirements in the previous

(25)

Figure 2: The SDLC (Pinheiro 2018)

3. Implementation: Code is produced by developers. Often the longest phase of the SDLC.

4. Testing: The code is tested against the system requirements. Includes different types of testing methods such as functional and acceptance testing.

5. Maintenance: Upkeep and updating of the system as it is used by customers.

2.3.1 Traditional Agile Development

Agile development is strongly linked to iterative and incremental develop-ment suited where requiredevelop-ments change rapidly, or there is a high competition in the product field (Dima & Maassen 2018). The agile methodologies are ap-plicable especially in the software and IT industry as it is highly volatile, and demands new features to be implemented quickly (Highsmith & Cockburn 2001, Abrahamsson et al. 2002). The characteristics of agile development allow the shortening of projects’ life cycles through for example iterative

(26)

time-bound cycles from one to six weeks, adaptability for fewer risks, mini-mal documentation, continuous integration of code, and the encouragement of collaborative and communicative working style (Miller 2001).

There exist many different versions of agile development each with its own set of activities, however still sharing the fundamental characteristics of agile development. Scrum and Test-Driven Development are some main variations of agile development just to name a few (Dima & Maassen 2018). Agile development is a methodology with an iterative approach compared to SDLC which is a process of design for a product or service proceeding in consecutive stages. According to Hoda et al. (2018), agile development has been one of the most dominating methodologies in software engineering specifically. Similarly, the studied company applies agile methodologies in the projects in-house but also when working externally with the customer.

2.3.2 Green Agile Development

Assessing the environmental impact of products and services through stan-dardized techniques such as calculating the carbon footprint, or conducting life cycle assessments are often intricate and expensive, sometimes even per-formed after the product is available on the market (Acaroglu 2018). Re-cently, however, researchers realized that agile methods can be used in the development of green and sustainable software and that it is of benefit to integrate environmental aspects of sustainability already in the development phase to ensure that it is regarded throughout the whole process (Dick et al. 2013). In this paper, the modified versions of agile development models for environmental sustainability will be referred to as ”Green Agile Develop-ment”.

Previous research has investigated success factors and practices of green agile development for global software development vendors that can be di-rectly integrated into work processes (Rashid & Khan 2018a,b). Through an extensive systematic literature review, 16 success factors were identified and 6 of them were defined as critical (Rashid & Khan 2018a). These are (1) Ef-ficient utilization of time and computing resources, (2) Rich communication

and collaboration, (3) Minimal documentation, (4) Polymorphic design1, (5)

Green and sustainable management of the product life cycle, and lastly, (6) Continuous validation.

1_{The ability in programming to present the same interface for different underlying data}

(27)

According to Rashid & Khan (2018b) and Taina (2011), efficient utiliza-tion of time and computing resources contribute to green and sustainable software through substantial time saving as well as the need for less comput-ing resources as the product can be delivered in a much shorter time span. The practices that promote this factor include, for example, development of reusable prototypes, pair programming, iterative development, and accom-modating changes in the requirements. Furthermore, rich communication and collaboration may have a direct impact on sustainable software devel-opment as stakeholders are closely involved in the project, therefore, having the opportunity to communicate new requirements and less changes to occur (Taromirad & Ramsin 2008). Agile practices that enable this are for exam-ple keeping small teams, encouraging face to face meetings, as well as digital communication. Additionally, it is stated by (Rashid & Khan 2018b) that producing minimal documentation, which is already a central part of agile development compared to its counterparts, can result in a greener SDLC through planning interaction sessions and encourage informal communica-tion. Practices for polymorphic design can include for instance, updating the design as per changes in the customers’ requirements. To ensure a green sustainable management of the product life cycle, the practices recommended are using an energy estimation software such as ”Green Tracker”, and arrang-ing milestones to ensure that energy requirements are fulfilled.

Figure 3: Process Enhancements for Sustainable Software Engineering (Dick et al. 2013)

(28)

be integrated into software engineering processes with agile methods. This model is focusing mainly on the direct environmental impacts mentioned previously in section 2.1 such as energy consumption, defined by Berkhout & Hertin (2001). The enhancements consist of two cycles: the first cycle focuses on the effects and impacts of the development process, the second focuses on the impacts and results from distributing the end-product or service. Dick et al. (2013) suggests 7 different enhancements that fit well into the existing agile software development methodology (see Figure 3). The enhancements are:

1. Process Assessment: Initial data collection phase for a life cycle assessment or carbon footprint analysis with a focus on the impacts of the software itself. Data collection should cover first-, second-, and third-order effects (see 2.1.1) during the development, usage, and end of life phases.

2. Sustainability Reviews and Previews: Review work done on sus-tainability issues, and preview developed solutions for those issues, and estimate success. This part focuses on the impacts of distribution and

software use. This should be performed at about two-thirds of an

iteration through code reviews, performance measurements, or other sustainability metrics.

3. Sustainability Journal: (1) and (2) are combined in the sustainabil-ity journal. The journal is a short log of the process enhancements. 4. Interim Sustainability Presentations: At the end of each

itera-tion, the sustainability work is reported by the developers to customer representatives.

5. Final Sustainability Presentation and Report Release: Formal presentation and compilation of final report by the sustainability exec-utive, of findings logged in the sustainability journal, and reports sent by each iteration. This is done by the end of the software development process.

6. Sustainability Retrospective: Discuss lessons learned, best prac-tices, decisions, and group reflections to improve sustainability work for future projects.

(29)

2.4 Enablers and Barriers of Sustainable Practices

Some sustainable best practices and tools have been identified through the findings discussed in previous sections. Naturally, the next step is to deter-mine the enablers and barriers of implementing those practices in an organi-zation. The first section describes the adoption of sustainable practices in a general manner, followed by the views of software engineers in particular.

2.4.1 Organizational Barriers

Adoption of sustainable practices, whether it is on an individual level or an organizational level, comes along with several barriers or enablers. Seidel et al. (2010) found in their study that one personal factor for enabling sus-tainable IT business practices was mainly motivation. Motivation divides into intrinsic motivation (the individual’s desire to perform a task for his

own sake) and extrinsic motivation (contingent rewards) (B´enabou & Tirole

2003). Both intrinsic and extrinsic motivation play a big role in adopting new business practices or technologies (Davis et al. 1992). However, in the particular case of adopting new business practices for sustainability, intrinsic motivation played the biggest role out of the two (Seidel et al. 2010). In-trinsic motivation to be environmentally friendly was important to achieve bottom-up support and spread throughout the organization.

From an organizational point of view, the biggest enablers for adoption of sustainable IT business practices were strategy definition, organizational support, and traceability, according to the same study by Seidel et al. (2010). Having clear strategic targets and introducing measures for environmental is-sues was shown to be important to introduce new sustainable practices. This goes hand-in-hand with organizational support in the form of commitment from executives and sharing responsibility (Seidel et al. 2010). Traceability referred to transparency and measurement, which was highly relevant for the adoption of sustainable practices throughout the organization. Lacking these organizational enablers served as a barrier to adoption.

Institutional barriers to adopting sustainable technology have also been identified by Wang et al. (2020). Barriers to the adoption of energy-efficient technologies may arise either from market barriers such as high costs or from factors within the organization, namely institutional factors. For example, if an organization lacks the expertise or capacity to develop specifications for a sustainable product available on the market, it most likely will not

(30)

adopt the product. Internal factors such as knowledge and capacity are more significant, even if the product is cost-effective and will reduce the environmental impact of the organization (Wang et al. 2020).

Organizational culture also plays a big part in whether firms care for sus-tainability matters and how sussus-tainability can be achieved. Linnenluecke & Griffiths (2010) identified that organizations can display disunity in assump-tions, beliefs, and values regarding sustainability. Through the existence of subcultures within the organization, employees can hold different atti-tudes towards sustainability within each subculture. Organizational rigidity, subcultures, and lack of knowledge are barriers to integrating sustainable principles (Linnenluecke & Griffiths 2010).

Furthermore, Matos & Clegg (2013) state that it is more likely for or-ganizational change to occur if the topic of sustainability naturally emerges rather than it being imposed onto the employees, meaning that the employees themselves initiate directive. Examining employees’ motivations, attitudes, and discretionary behaviors in relation to sustainability therefore seems im-portant to understand how implementation can be enabled and sustained.

2.4.2 Professional Barriers

Barriers to the adoption of sustainable practices from the practitioners’ per-spective are many. Programmers have low awareness and are not knowl-edgeable of software energy consumption and how to reduce it (Chitchyan et al. 2016, Pang et al. 2015, Li & Halfond 2014). For example, they do not know the programming methods for reduced energy consumption, nor do they know which functions in the system that utilizes the highest amount of energy. Often, they are not even asked to modify the software to improve its energy efficiency as there is higher prioritization of other requirements such as quality and performance.

Similar results were discovered by Manotas et al. (2016), stating that practitioners are not as successful at developing green applications as they could be due to lack of information and support infrastructure. The lack of knowledge is according to Pinto & Castor (2017) connected to the lack of tools available for software developers to detect and determine the energy consumption of the programs they develop. Software developers who want to reduce the knowledge gap are relying on non-empirical evidence such as Q&A websites, blog posts, or YouTube videos when trying to optimize energy consumption which may be both unreliable and incorrect (Pinto & Castor

(31)

2017). Chitchyan et al. (2016) suggest that improvements have to be made already during education where sustainability principles should be added to courses in software engineering.

Additionally, only 3% of end-users complain about energy-related issues, and therefore it is not brought up to attention by the developers (Pang et al. 2015). This stems from a lack of knowledge regarding energy consumption from the end-users just as the programmers themselves. As the end-users are not knowledgeable of how software directly or indirectly affects the envi-ronment, they are not able to demand organizations to prioritize or reduce the environmental impact of the software. Besides government policies, cus-tomer demand is one of the big drivers that force organizations to become more sustainable (Du et al. 2013). Unfortunately, the absence of this demand may be the reason why programmers are not giving energy requirements a high priority (Pang et al. 2015).

Similar results were discovered by Groher & Weinreich (2017) stating that customer loyalty and customer satisfaction are important considera-tions when practitioners are reflecting on sustainability. In this case, the practitioners did not mention environmental sustainability in their software development process which meant that customer requirements regarding the environmental aspect were absent (Groher & Weinreich 2017). Therefore, customers have to be educated regarding the sustainability within require-ments elicitation, and software users have to be informed regarding the con-sequences of their choices (Chitchyan et al. 2016).

Moreover, as the complexity and scale of software systems increase, so does the complexity of stakeholder relations. Consecutively, making it diffi-cult to identify the boundary of the system as well as in gaining a holistic view of the system. An example of a large-scale complex system could be an application that runs on a cloud computing platform, connected to several web services. Measuring the environmental impact of a system such as this one is difficult and will be limited by the stakeholders’ own understanding of the system (Zhang et al. 2011).

(32)

3 Methodology

This chapter presents the methodology of this study. It begins by describing the research design and motivating the choice of a case study. Further, an overview of the research process is given followed by a presentation of the methods for data collection. Subsequently, the process of data analysis is ex-plained followed by an assessment of the research quality of the study. Lastly, research ethics are discussed.

3.1 Research Design

To best answer the research questions, a qualitative single case study was chosen as the research design of this study. Case studies are preferred when an in-depth inquiry into a topic or phenomenon within its real-life setting is desired (Yin 1994), in this case, the real-life setting being a Swedish technical consulting company.

To understand and get insights into how software developers and en-gineers can decrease their environmental impact, as well as understanding what hinders software engineers and developers in adopting practices and tools to decrease their environmental impact - and why - a single case study was preferred considering case studies are well fitted with ”why” and ”how” questions (Saunders et al. 2015).

The reason for studying a single case is due to the nature of the case be-ing very typical, i.e., software development usually works similarly in various companies. The hindering factors for the adoption of environmentally con-scious practices may differ from organization to organization as well as from individual to individual, however, the purpose of this study is to investigate those factors in this particular context. Therefore, a single case study was deemed fit to fulfill the purpose.

Furthermore, investigating a single case is also more manageable and allows for an extensive amount of empirical data to be collected from the employees of the case company (Saunders et al. 2015). What is important to note, however, is that single case studies are limited in their generalizability because they are focused on one single instance (Stake 2005). With that said, single case studies can nonetheless provide useful insights in their specified context.

The characteristic of the research strategy was exploratory, meaning the research is set out to understand what is happening, as well as seeking out

(33)

new insights regarding environmental concerns in software development and software engineers and developers (Runeson et al. 2012). An exploratory study fits well as the aim of the study is to investigate the possible factors that hinder software engineers and developers in being environmentally conscious. Here, we are trying to clarify our understanding of this specific phenomenon. Additionally, the exploratory research approach is advantageous when there is a lack of previous research in the subject area (Blomkvist & Hallin 2015). The primary data type for this study was qualitative in the form of semi-structured interviews. Together with in-depth interviews, semi-semi-structured interviews are one of the preferred methods of data collection when doing an exploratory study as it provides contextual material for the study (Saunders et al. 2015).

Qualitative case studies are often associated with an inductive approach, however, this study had chosen an abductive approach to theory development where inductive reasonings are developed and deductive ones are tested

it-eratively throughout the research (Saunders et al. 2015). Therefore, the

literature review was constantly revisited and complemented as new findings from the interviews emerged. Ultimately, the intention was to ensure that the research questions were answered.

3.1.1 Case Company

The case of interest is a privately-owned technical consulting company based in Sweden. The company is offering consulting services in areas such as dig-itization, quality assurance, project management, and product development. Since its founding in 2002, the company has grown to operate in over 10 dif-ferent locations across Sweden, with over 700 employees in various fields of expertise. They put a lot of emphasis on values such as teamwork and team cooperation, trust, openness, and inclusion. Sustainability is also something that is frequently mentioned in conjunction with their values.

The company is divided into four business units, each working with dif-ferent technologies and services. Some of these business units, including the one that is investigated in this thesis, have previously been stand-alone com-panies, meaning they were merged with the case company approximately two years ago.

The business unit of interest in this thesis is working closely with the development of cloud services, IT platforms, web applications, as well as back-end systems. The main cloud providers that the developers are working

(34)

with are Amazon Web Services (AWS) and Microsoft Azure. Other business units within the company are providing services in for example construction, business development, and embedded systems.

3.2 Research Process

To effectively carry out the research, a structured research process was de-veloped. The research was shaped by a non-linear process consisting of four main steps illustrated in Figure 4.

The research process began by formulating a research topic and research questions together with the case company. The research questions were up-dated throughout the research process as new findings changed the direction of the study. Following the formulation of the research topic, an extensive literature review was carried out to attain a greater understanding of sus-tainability in software development. Five well-defined themes were found in literature, (1) sustainable software engineering, (2) cloud technology, (3) energy efficiency, (4) green software development life cycles, and lastly, (5) enablers and barriers. The findings from the literature review served as a backbone for the study and were useful in formulating interview questions for data collection. This section was developed iteratively as new perspectives and findings emerged throughout the process.

The third stage consisted of the investigation of the case and the collection of empirical data. The data was collected in the form of semi-structured interviews at the case company and analyzed through a thematic analysis.

The themes were in the fourth and last step discussed together with previous literature where similarities and dissimilarities were pointed out. The research questions were then answered, and conclusions made.

(35)

3.3 Data Collection

Multiple sources of data were collected to ensure data triangulation and to achieve a high level of construct validity (Gibbert et al. 2008). These included both secondary sources in the form of peer-reviewed articles in the literature review, as well as primary sources, in the form of semi-structured interviews at the case company. The interviews were performed with employees work-ing at the case company with various roles in software engineerwork-ing such as developers, architects, and testers. Different roles within software engineer-ing were of interest as the perception of sustainability and way of workengineer-ing might differ between the roles. Employees on the managerial level were also of interest (such as product owners and CTOs) as those might impact the requirements of the software as well as affect the values set at the company towards environmental concerns.

3.3.1 Secondary Data Collection

As previously mentioned, the secondary data collection mostly consisted of peer-reviewed articles used to construct the literature review and to build a base of knowledge of key theories, concepts, and ideas of the field of study. The literature was critically reviewed according to the guidelines presented by Saunders et al. (2015). The guidelines included previewing, annotating, summarizing, and comparing and contrasting the literature for effective read-ing. Additional functions of the literature review were to help generate and refine the research topic as well as support or counter the empirical findings (Creswell 2018).

The search for articles included an initial broad exploration of Google Scholar for scholarly literature. Additionally, the databases Science Direct, ACM Digital Library, and IEEE Xplore were utilized to gather knowledge from multiple disciplines. Examples of keywords used in the search were ”green software development”, ”sustainable software development”, ”energy usage” AND ”software development”, ”identity” AND ”software engin*”. The asterisk in the search was used as a wildcard symbol to broaden the search by finding words that start with the same letters.

3.3.2 Primary Data Collection

The primary data collection consisted of 10 semi-structured interviews per-formed with various employees in different roles at the case company. The

(36)

reason for performing semi-structured interviews was to ensure that the de-sired topics were covered during the interviews, as well as to make room for additional questions. Furthermore, this type of interview allowed for thoughts and conversations to be deepened and the ability to explore areas that were not thought of beforehand (Saunders et al. 2015).

Table 2: Overview of the conducted interviews

Respondent Date Duration Title / Role Guide A 2021-03-08 40 min Systems Developer A.2 B 2021-03-11 50 min Lead Developer A.2 C 2021-03-15 60 min Cloud Architect & Team Lead A.2 D 2021-03-16 30 min Team Manager, Recruiter,

& Business Development

A.1

E 2021-03-17 40 min Team Manager & Consultant A.1 F 2021-03-18 60 min Consultant & Back-end Lead A.2 G2 _2021-03-22 _{30 min} Enterprise Architect &

Product Owner

A.1

G 2021-03-23 60 min Enterprise Architect & Product Owner

A.1

H 2021-03-24 30 min IT Architect A.2 I 2021-03-26 60 min CTO, Team Lead &

Cloud Architect

A.2

J 2021-03-26 30 min Solutions Architect & Team Lead

A.2

The interviewees were sampled based on the guidance of the supervisor at the case company which recommended employees based on the role, com-petence, and experiences requested by the researcher. The supervisor at the

(37)

company had a better understanding of the company structure and its em-ployees, therefore it was considered a reliable source for guidance. Various roles within software engineering were requested for interviews, mainly soft-ware developers, softsoft-ware architects, and tech leads. Employees with the capability to determine or affect the requirements of software products were also of interest as those may regulate what environmental requirements there should be during the development. These included for example product own-ers, CTOs, and managers. All interviewees but one were male. An overview of all interviews held is given in Table 2.

The sampling size of 10 interviewees was regarded as sufficient based on research by Guest et al. (2006) which stated that the saturation point for non-probabilistic sampling methods occurred between 6-12 interviews. The topic of research quality will be discussed further in section 3.5.

Two general interview guides were developed beforehand (see Appendix B) which were somewhat adapted for every role to get more out of the par-ticipants’ experiences and competence in different areas of the company. The interview guides ensured that the important parts were not left out or for-gotten and increased the efficiency of the interviews. Even though the inter-views were adapted based on the topic and aim of the interview, the main goal persisted of understanding how sustainability can be incorporated, and the constraints of this process within the organization and its employees.

Initially, the interviewees were asked for consent (more on this in section 3.6). The interviews were performed remotely through video conferencing tools such as Zoom or Microsoft Teams. These provided the functionality of built-in recording, which simplified the process of data analysis in later stages as the data transcription would become more accurate. This also ensured that the data could be studied multiple times to eliminate any misconceptions during the interviews. The interviews were conducted in either Swedish or English based on the preference of the participants. Ultimately, the data was transcribed in preparation for data analysis.

3.4 Data Analysis

To analyze the data from the semi-structured interviews, a thematic analysis was performed. Thematic analysis, which is a well-known generic method for analyzing qualitative data, can derive both implicit and explicit ideas within interviews through the identification of codes and themes (Guest 2012).

(38)

integrat-ing large and disparate amounts of data from different transcripts and notes, being able to test explanations and theories, as well as drawing and verifying conclusions. It is a systematic, yet flexible approach to analyze data as it follows an orderly and logical way consisting of a four-step process (Saunders et al. 2015). The steps are as follows: (1) familiarising with data, (2) coding, (3) searching for themes and relationships, and lastly, (4) refining.

The first step included the production of transcribed material derived from the recorded interviews. These were made manually to develop famil-iarity with the data so that the analytical procedures become more manage-able. During the familiarity process, possible codes and themes emerge that aids the analysis in later stages.

The second step involved coding, which is the method of categorizing data with similar meanings (Guest 2012). Words, sentences, or paragraphs were labeled with codes that symbolize the meaning of the extract. The codes were reused for extracts that had similar meaning as previous parts throughout the transcripts. The codes consisted of either short phrases or single words. Furthermore, parts of the transcript that encompassed multiple meanings were labeled with several codes. All codes were subsequently compiled in a document where themes based on the relationship and pattern of those codes could be identified. The themes contained multiple codes or consisted of one single code which had particular significance for the research question, elevated to become its own theme. The formulation of themes began as soon as all transcribed material was coded.

Refining the themes and codes was the last step of the analysis process, where the transcribed material would be iterated to adjust relationships and meanings. The purpose of this step was to reorganize the material and eval-uate it as the last step before compiling the results.

An overview of the developed themes and codes can be found in Appendix C.

3.5 Research Quality

Even though case studies have provided the research with ground-breaking insights, it has been prone to concerns regarding methodological rigor in terms of its validity and reliability (Gibbert et al. 2008). Assessing the rigor of a paper can be based on numerous criteria. In this paper, rigor will be assessed from a positivist tradition: in terms of internal validity, construct validity, external validity, and reliability according to Gibbert et al. (2008)

(39)

and Aguinis & Solarino (2019). As stated by Gibbert et al. (2008), the positivist model was adopted because it is a basis of one of the most respected case study researchers, namely Yin (1994).

3.5.1 Validity

Validity in this section will be discussed in terms of three aspects: internal, construct, and external validity as per Gibbert et al. (2008).

Internal validity or logical validity refers to the causal relationship

be-tween variables and results. It is about determining to what extent the

researcher can argue and reason for the research conclusions and how well the evidence supports the claim about cause and effect. Therefore, internal validity is directly connected to the data analysis phase (Gibbert et al. 2008). To establish internal validity, theoretical triangulation has been used as a means to interpret the findings of this study. Theoretical triangulation involves the use of multiple perspectives to analyze the same data set (Denzin 2006). The literature review serves as a base for this analysis, which consists of articles from a broad range of different disciplines and perspectives such as management and computer science. Chapter 5 discusses the findings based on the theory gathered in the literature review.

Construct validity refers to what extent the research is accurately repre-senting the object of study or reality. It is the degree to which the study investigates what it claims to investigate. Therefore, construct validity is considered during the data collection phase (Gibbert et al. 2008).

To increase the construct validity of the paper, the phenomenon of study has been looked upon from different angles through data triangulation. Mean-ing, different strategies have been adopted to collect data (Denzin 2006). In this case, data has been collected mainly from previous literature in the form of articles as well as interviews to get a more accurate representation of re-ality. Furthermore, the process of data collection and the way it has been analyzed have been demonstrated in previous sections, which also amounts to construct validity.

External validity, often known as generalizability, refers to the belief that theories and findings can be applied not only in the setting of which they were studied but in other settings as well (Gibbert et al. 2008). Case studies cannot allow for statistical significance (for example give conclusions about a population), however, they can generalize empirical observations to theory (Yin 1994). This is referred to as analytical generalization. Nevertheless,

(40)

single case studies like this one may be difficult to generalize, however, they can still provide useful knowledge of the specific context of the study.

3.5.2 Reliability

Assessing the reliability of the study is important to ensure that subsequent researchers arrive at the same insights if they conducted the study according to the same methodology once more (Gibbert et al. 2008).

Reliability consists of two parts, transparency and replication according to Aguinis & Solarino (2019). With a greater degree of transparency, the trustworthiness and implications of the study’s result can more easily be understood (Denzin & Lincoln 1994). For other scholars to extend current research, the thought processes, analysis, and theories have to be recognized and therefore, transparency is of great importance (Moravcsik 2014). The degree of transparency decides the level of replication (exact, empirical, or conceptual replication) that other scholars can perform based on the study (Aguinis & Solarino 2019).

To achieve a high level of reliability in this study, the methodology of the study has been shared, in this instance a single case study. The research set-ting has also been explained in previous sections regarding the case company. The sampling procedures, as well as the saturation point, have briefly been discussed together with an overview of the relative importance of the partic-ipants given in Table 2. This allows for the identification of particpartic-ipants and cases with similar characteristics (Aguinis & Solarino 2019).

Furthermore, the interview guide has been shared, however, replicating semi-structured interviews can be difficult as some questions may be open-ended and research participants can react differently to these. Nonetheless, findings from semi-structured interviews, in general, are not necessarily in-tended to be replicated since they reflect the research context in a specific instance of time (Saunders et al. 2015).

Documentation in the form of transcripts has not been shared due to confidentiality and ethical reasons which will be further discussed in the next section. However, the reason for disclosing raw data is only for other researchers to be able to perform an exact replication with the intent to, for example, find errors in data analysis (Aguinis & Solarino 2019).

Lastly, the codes and themes formulated as a part of data analysis have been shared for a higher degree of transparency and replication.

(41)

3.6 Research Ethics

Ethical concerns have been regarded during the research process based on the

guidelines from the Swedish Research Council (Vetenskapsr˚adet 2002). The

guidelines are encompassed of four ethical principles which are: (1) informa-tion requirement, (2) consent requirement, (3) confidentiality requirement, and lastly (4) good use requirement.

The information requirement has been regarded through informing inter-view participants of the purpose and why they are of relevance for the study before each interview. In conjunction, interviewees were made known that participation is voluntary and that they are allowed to leave as they desire during the process.

As for the consent requirement, the participants were personally asked for consent before each interview. The interviewer made it known that the participants would be audio and video recorded, and their information

tran-scribed for it to be analyzed properly. The participants’ consent to the

aforementioned information was ensured before the data collection process proceeded any further. The participants themselves stated their availability in terms of day and time and were allowed to reschedule if needed.

The confidentiality requirement was regarded through keeping informa-tion that could be used to identify any of the participants anonymous. This was ensured by assigning each participant with an ID as can be seen in Table 2. Sensitive information such as the identity of the participants was kept in a location only accessible by the researcher. The identity of the case company was also kept anonymous as agreed between researcher and supervisor at the company.

Lastly, the good use requirement entails that all collected information regarding individual participants in the study will only be used to fulfill the research purpose.

Ecological Sustainability in Software Development: The Case of a Technical Consultancy Firm

Ecological Sustainability in

Software Development

The Case of a Technical Consultancy Firm

Ecological Sustainability in Software

Development

The Case of a Technical Consultancy Firm

by

Bercis Arslan

Ekologisk Hållbarhet inom

Mjukvaruutveckling

En Fallstudie inom ett Teknikkonsultbolag

av

Bercis Arslan

Contents

List of Figures

List of Tables

Acronyms

Acknowledgements

1

Introduction

1.1

Background

1.2

Problem Formulation

1.3

Purpose

1.4

Research Questions

1.5

Delimitations

1.6

Outline

2

Literature Review

2.1

Sustainable Software Engineering

2.2

Energy Consumption

2.3

Software Development Life Cycle

2.4

Enablers and Barriers of Sustainable Practices

3

Methodology

3.1

Research Design

3.2

Research Process

3.3

Data Collection

3.4

Data Analysis

3.5

Research Quality

3.6

Research Ethics