Faktorer för refaktorisering vid teknisk skuld

(1)

Faktorer för refaktorisering vid teknisk skuld

En kvalitativ studie mellan olika branscher inom mjukvaruprojekt

Författare: Sebastian Börjesson Författare: Viktor Bolinder

Examensarbete

(2)

Abstrakt

I det teknikväxande samhället bidrar mjukvaruutveckling till stora it-relaterade utgifter och investeringar. Industrier utvecklar stödjande programvara för sin produktion och mjukvaruföretag levererar digitala system för kunder som behöver uppfylla ett behov. Utvecklingsteamen jobbar under press för att leverera så bra programvara som möjligt och samtidigt hålla sig inom budgetramar som satts upp enligt avtal. För att nå sina mål kan utvecklare introducera teknisk skuld i systemen, dvs. att bristfälliga lösningar byggs före kvalitetslösningar. Teknisk skuld behöver inte vara ett problem för stunden men på sikt kan konsekvenserna av skulderna bli problematiska och kräva resurser att kunna hanteras. Tidigare forskning visar att drygt en fjärdedel av en utvecklares tid går åt för att hantera teknisk skuld. Vid åtgärdande av teknisk skuld brukar refaktorisering vara ett vanligt verktyg att ta till, vilket innebär att skriva om källkod utan att förändra det visuella beteendet för användaren.

Syftet med följande uppsats är att undersöka olika branscher som utvecklar mjukvara och deras hantering av teknisk skuld genom att belysa vilka faktorer som avgör om och när refaktorisering skall ske, och hur argumentationerna för refaktorisering skiljer sig åt mellan branscherna. Uppsatsen baseras på kvalitativa intervjuer med aktörer från både industri- och mjukvaruföretag. Empirin från intervjuerna analyseras med hjälp av en ontologisk mappning kring typer av teknisk skuld, som sedan har applicerats i ramverket Technical Debt Quadrant.

Resultatet visar att industribranschens avgörande faktorer för refaktorisering var konsekvensen av skuldens påverkan samt hur pass förändringsbenägen den skuldbelagda funktionaliteten var. Branschen ansåg att tidpunkten för att refaktorisera var bäst lämpad i samband med vidareutveckling av en funktion som innehöll teknisk skuld. I konstrast visade resultatet för mjukvarubranschen att faktorerna för refaktorisering var konsekvensen av skuldens påverkan samt vilka ekonomiska förutsättningar som fanns för projektet. Tidpunkten för när refaktorsering var lämplig avgörs när företagen anser att avkastningen för investeringen att refaktorisera är som högst eller när inget annat val finns.

Resultatet visar även att branscherna hade olika fokus för hur de argumenterar för refaktorisering. Industrin argumenterade mer med systemet i fokus, hur det kunde förändras med tiden och att det skulle bli lätthanterligt att underhålla med tiden.

Mjukvarubranschen hade mer ekonomiska aspekter som argument, dvs. att de analyserade situationen och beslutade huruvida refaktoriseringen är lönsam eller inte.

Nyckelord

Teknisk skuld, Refaktorisering, Technical Debt Quadrant, Industribranschen, Mjukvarubranschen.

(3)

Abstract

In the technology-growing society, software development contributes to large it- related expenditures and investments. Industrial companies develop supporting software for its production and software companies deliver digital systems for customers to satisfy a need. The development teams work under pressure to deliver as good software as possible and at the same time stay within budget frameworks according to agreements. To achieve their goals technical debt in systems can be introduced, which means that deficient solutions are built before quality solutions.

Technical debt does not have to be a problem at first, but in the long run the consequences of the debts can become problematic and require resources to be managed. When fixing technical debt, refactorization is a common tool to resort to, which means to rewrite source code without changing the visual behaviour to the user.

Previous research shows that just over a quarter of a developer's time is spent managing technical debt.

The purpose of the thesis is to examine different industries that develop software and their management of technical debt by highlighting which factors determine if and when refactoring should take place, and how the arguing for refactorization differentiate between the industries. The thesis is based on qualitative interviews with actors from both industrial and software companies. The empirical data from the interviews are analysed with the help of an ontological mapping around types of technical debt, and later applied in the framework Technical Debt Quadrant.

The results show that the industry companies' decisive factors for refactorization were the consequence of the debt's impact and how prone to change the indebtedness functionality was. The industry considered that the time to refactorize was best suited in connection with the further development of a function that contains technical debt.

In contrast, for the software companies the results showed that the factors for refactorization were the consequences of the debt's impact and what financial prerequisites there were for the project. Appropriate timing for refactoring was determined when the companies consider that the return on the investment to refactorize is at its highest or when there is no other choice.

The results also show that the industries had different focus on how they argue for refactorization. The industry argued more with the system in focus, how it could change over time and that it should be easy to maintain while the software industry had more economic aspects as an argument, ie. that they analyzed the situation and made choices whether the refactorization is profitable or not.

(4)

Tack

Vi vill rikta ett stort tack till alla informanter som har ställt upp och för er medverkan i denna studie. Sedan vill vi också rikta ett stort tack till vår handledare

Fisnik Dalipi som genomgående varit en stöttepelare under vårt arbete samt bidragit med bra tips och råd. Sist men inte minst vill vi tacka alla personer i vår

närhet som har stöttat och uppmuntrat oss i detta arbete.

Växjö, Linnéuniversitetet, Juni 2021

Viktor Bolinder Sebastian Börjesson

(5)

Innehållsförteckning

1 Inledning 1

1.1 Tidigare forskning 1

1.1.1 Industribranschen 2

1.1.2 Mjukvarubranschen 3

1.2 Problemområde, syfte & frågeställningar 4

1.3 Avgränsningar 4

2 Teoretiskt perspektiv 6

2.1 Begreppsförklaring 6

2.2 Innebörden av teknisk skuld 6

2.2.1 Refaktorisering 7

2.3 Technical Debt Quadrant 7

2.3.1 Sammanslagning av faktorer i ramverket 8

2.4 Klassificering av teknisk skuld 9

2.5 Applicering av Technical Debt Quadrant 11

3 Metod 13

3.1 Vetenskaplig ansats 13

3.2 Insamling av data 13

3.2.1 Urval 14

3.2.2 Intervjuer 14

3.3 Analys 15

3.4 Reliabilitet och validitet 15

3.5 Etiska överväganden 16

4 Resultat 17

4.1 Teman 17

4.2 Typer av teknisk skuld 17

4.3 Faktorer för refaktorisering 20

4.4 Tidpunkt för refaktorisering 23

4.5 Strategi 24

5 Analys 27

5.1 Industribranschen 27

5.1.1 Vårdslöst och Avsiktligt 27

5.1.2 Vårdslöst och Oavsiktligt 28

5.1.3 Genomtänkt och Avsiktligt 29

5.1.4 Genomtänkt och Oavsiktligt 30

5.2 Mjukvarubranschen 30

(6)

5.2.1 Vårdslöst och Avsiktligt 31

5.2.2 Vårdslöst och Oavsiktligt 32

5.2.3 Genomtänkt och Avsiktligt 32

5.2.4 Genomtänkt och Oavsiktligt 33

6 Diskussion 34

6.1 Typer av skuld 34

6.2 Faktorer för refaktorisering 35

6.3 Tidpunkt för refaktorisering 35

6.4 Strategi 36

6.5 Metodreflektion 37

7 Slutsats 38

7.1 Vidare forskning 39

Referenser 40

Bilagor

Bilaga 1: Informationsbrev Bilaga 2: Intervjuguide

(7)

1 Inledning

Utveckling av mjukvara stod för den största andelen av företags totala it- relaterade utgifter och investeringar år 2019 (SCB 2020). Mjukvaruföretag utvecklar system och levererar till kunder för att generera intäkter, medan exempelvis industrier utvecklar mjukvara för att kunna stödja sin kärnverksamhet. Många utvecklingsprojekt har en snäv tidsram tills det skall levereras till kund, vilket kan leda till att mjukvara levereras med snabba lösningar istället för kvalitetslösningar.

Detta kan konceptualiseras med begreppet “teknisk skuld”.

Begreppet “teknisk skuld” infördes av Ward Cunningham på 1990-talet. Begreppet grundade sig på att utvecklare inom mjukvarubranschen inte levererade robust eller optimerad kod för sina produkter. Projektet hamnade då i en skuld tills den icke- robusta koden blev optimerad för sitt syfte. Även om koden fungerade för stunden fanns risk att programmet blev ohanterligt ju längre tiden gick och nya funktionaliteter byggdes på. Detta kan leda till att det måste finnas resurser i form av specialiserade programmerare som vet hur systemet ska fungera och hur skulden ska betalas tillbaka (Cunningham 1992).

Metaforen teknisk skuld har enligt Kruchten (2012) efterliknats vid en finansiell skuld. En finansiell skuld betalas tillbaka med beloppet, plus en ränta baserat på det lånade beloppet. Likt detta betalas den tekniska skulden genom att refaktorisera den skuldbelagda koden. Räntan representerade den extra kostnaden som tillkom för att underhålla och vidareutveckla mjukvaran pga. komplikationerna som skapats av den tekniska skulden.

Teknisk skuld bör vara reserverat för utvecklare som tar ett noggrant beslut att utforma en designstrategi, i vilken mjukvaran blir ohållbar på lång sikt men ger en kortsiktig fördel för att exempelvis kunna släppa ny version av en programvara (Fowler 2009). För att åtgärda en definierad teknisk skuld så används ofta refaktorisering av koden (Li, Avergiou & Liang 2015).

För att sätta ovanstående i ett större perspektiv publicerade fackföreningen Unionen en rapport som behandlade tjänstemännens IT-miljö. Rapporten visar att under år 2017 lade tjänstemän inom IT totalt 133,5 miljoner arbetstimmar på att hantera IT- relaterade problem (Unionen 2017). Sifforna indikerar att det måste finnas faktorer som leder till detta resultat.

1.1 Tidigare forskning

Nedan presenteras litteratur av tidigare forskning kring teknisk skuld. Litteraturen är baserad på vetenskapliga artiklar med studier inom mjukvaruutveckling inom både industri samt mjukvaruföretag. Ingen avgränsning har gjorts till någon specifik typ av system, utan syftet är att belysa olika typer av resultat kring vilka faktorer och indikationer som spelar in när teknisk skuldåtgärdas inom de olika branscherna.

(8)

Fördelen med att identifiera den tekniska skulden, dess typ och fastställa räntan leder till att det blir lättare att förstå hur stort problemet är och på så sätt kunna ta ett snabbare beslut (Guo, Spinola & Seaman 2016). Martini, Besker och Bosch (2016) hävdade att dokumentation av teknisk skuld medför ett långsiktigt perspektiv för utvecklingsteamen och fungerar som ett komplement till dokumentationen över ny funktionalitet. Det långsiktiga perspektivet leder till att det blir lättare att bygga vidare på den existerande koden och i sin tur få en stabilare arkitektur.

Verdecchia, Kruchten, Lago och Malavolta (2021) kategoriserade tre varianter av strategier för hantering av teknisk skuld på arkitektnivå. “Aktiv strategi”, som baserades på att utvecklingsteam hade kännedom av teknisk skuld och aktivt utvecklade planer för att hantera skulden. “Retro-aktiv strategi”, där teamen var medvetna om förekomsten av teknisk skuld men den hanterades inte förrän refaktorisering blev ofrånkomligt, exempelvis om en skuld förhindrade utvecklandet av en ny funktionalitet. Sista kategorin var “passiv strategi”, vilken syftade till att en skuld kunde bli för olönsamt att hantera då det skulle kosta alldeles för mycket för att refaktorisera. Här valde hellre teamen att bygga på den redan existerande skulden, chansen fanns att det aldrig behövde betalas tillbaka eftersom komponenten kunde komma att bytas ut vilket medförde att de inte behövde ta itu med skulden.

1.1.1 Industribranschen

Undersöks mjukvaror som utvecklas internt inom industri så tenderar de till att vara komplexa system med långa livscyklar, vilket leder till att de måste underhållas i flera år medan de används. Det är viktigt att försäkra sig om att systemens design och funktionaliteter inte leder till teknisk skuld då det kan kräva resurser att underhålla och utöka ett system med hög skuld (Sharma, Suryanarayana & Samarthyam 2015).

Ampatzoglou.A, Ampatzoglou.A, Chatzingeorgiou, Avgeriou, Abrahamsson, Martini, Zdun och Systa (2016) belyste faktorer när de studerade relationen mellan teknisk skuld och ett systems förväntade livslängd. System med längre planerad livscykel (10–30 år) var en faktor som bidrog till att systemen fick mer tillägnade resurser för underhåll av teknisk skuld, i 66,7% av fallen. Författarna såg även att i system med kortare livscykel (mindre än 10 år) fick 54.6% av fallen mindre resurser för underhåll pga. att de ansågs vara mindre viktiga.

Utöver detta hävdar dock Codabux och Willams (2013) att mjukvaruutveckling inom industri hanterade den tekniska skulden utifrån kundens behov först, dvs. om ny funktionalitet skulle byggas på det befintliga systemet. Resurser för att åtgärda fel i kodbasen prioriterades då bort för att tillfredsställa kunden med nya funktioner.

Sharma, Suryanarayana och Samarthyam (2015) redogjorde för 76% av informanterna inte hade tid för att genomföra underhåll av koden de producerat då företagsledningen hellre ville lägga fokus på nya funktionaliteter. För att göra teknisk skuld hanterbart så borde det refaktoriseras regelbundet, och faktorerna som spelade in för refaktorisering var livscykeln, skuldens allvarlighetsgrad, dess påverkan på framtida utveckling samt processer internt inom organisationen (2015). Det som också kunde spela in var skuldens påverkan på systemet, där utvecklingsarbetet i värsta fall helt kunde stanna av och inte fortsätta förrän skulden hade återbetalats (Codabux & Willams 2013).

(9)

Ampatzoglou et al. (2016) beskriver att i 90% av komponenterna som de undersökt kunde teknisk skuld av typen test-skuld identifieras, kod-skuld i 80% samt arkitektonisk-skuld i 70% av fallen. Vidare identifierades även diverse indikationer inom varje specifik typ av skuld. Inom test-skuld upptäcktes avsaknad av unit-tester för att testa all funktionalitet i systemet, de fann även brister på antal automatiserade tester. Inom typen kod-skuld påträffades duplicerad kod samt brister i god kod-praxis.

Inom arkitektonisk-skuld fanns komplex kod och gammal teknik.

Ovanstående studier pekar på faktorer som industrin har som indikationer för teknisk skuld och åtgärdande som refaktorisering. Codabux och Willams (2013) hävdar att utvecklingsteamen har en förståelse för att minimera skulder har sina fördelar men de ligger lågt prioriterade i deras backlogg. När skulden väl åtgärdas så prioriteras system som planeras vara i bruk över längre tid.

1.1.2 Mjukvarubranschen

Inom mjukvarubranschen finns en annan aspekt kring mjukvaruutvecklingen. På grund av det ökade trycket att leverera mjukvara till kunder, tenderar projektledare att påskynda processen genom att lägga press på utvecklingsteamet att möta målsättningen. Konsekvensen av den ökande pressen kan leda till att utvecklare medvetet genererar teknisk skuld och levererar kod med temporära lösningar (Mensah, Keung, Svajlenko, Bennin & Mi 2017).

Aktiviteter som tillkommer på grund av närvaro av teknisk skuld varierar från att utföra mer testning, kodanalys, söka igenom dokumentation och refaktorisera. Stor del av ett projekts tekniska skuld visar sig ofta komma från problem som uppstår i källkoden (Besker, Martini & Bosch 2019). Moralen hos utvecklare kan därmed enligt Besker, Ghanbari, Martini och Bosch (2020) sänkas, mest på grund av att det förhindrar produktiviteten och det försvårar att kunna utföra sina huvudsakliga uppdrag.

Maldonando och Shihab (2015) beskriver, där fem open-source-projekt studerades, att de vanligaste typerna av skulder som programmerare tog sig an var designskuld, defektskuld, dokumentationsskuld, kravskuld och testskuld. Den som framstod mest i studien var designskuld, dvs. strukturen i kodbasen. Synonymt för alla typer av skulder är att de alla varit medvetna, då de lagts som kommentarer i källkoden och utvecklare med tiden kunde ta beslut huruvida åtgärder för detta skulle genomföras eller inte.

Guo, Spínola och Seaman (2016) menar att processen vid beslut kring att betala tillbaka den tekniska skulden kunde påverkas av flera faktorer. Faktorerna var kundens förväntningar, tillgängliga resurser inom utvecklingsteamet, räntan på skulden, hur statusen på de skuldinfekterade komponenterna såg ut samt hur skulden påverkade andra funktionaliteter. Yli-Hummo, Maglyas och Smolander (2016) bekräftar att refaktorisering behöver utfärdas för att möta kundens krav på en fungerande och robust programvara, men i vissa fall hanterades inte den tekniska

(10)

skulden förrän den blev så pass omfattande att det inte fanns något alternativ än att refaktorisera koden.

1.2 Problemområde, syfte & frågeställningar

Mot bakgrund av tidigare forskning, tyder på att industribranschen och mjukvarubranschen kan ha olika indikationer som avgör om eller när det är lämpligt att refaktorisera sin mjukvara. Studier kring teknisk skuld utgår från antingen industrins eller mjukvaruföretagens perspektiv, de har inte ställts emot varandra i en gemensam studie när ämnet har utforskats.

Besker, Martini och Bosch (2019) ser refaktorisering som “oundvikligt slöseri av tid”

eftersom drygt 23% av utvecklingstiden läggs på att hantera teknisk skuld, med andra ord att det läggs energi på tidskrävande aktiviteter som negativt påverkar produktiviteten. Lenarduzzi, Besker, Taibi, Martini och Fontana (2021) menar att företag måste ha en förståelse för om och när refaktorisering ska prioriteras med hänsyn till vidareutveckling och hantering av buggar.

Huvudfokuset för studien är att ta reda på vilka faktorer som avgör om och när en teknisk skuld bör refaktoriseras. Detta för att belysa om det finns skillnader kring hantering av teknisk skuld mellan branscherna, och redogöra vilka typer av skillnader det i så fall finns. På så vis fylls ett gap där vi jämför olika typer av utvecklingsteam och ställer industri- och mjukvarubranschen mot varandra.

Förhoppningen är att kunna styrka ifall agerande runt refaktorisering skiljer sig åt och vilka faktorer det beror på.

Syftet med studien blir därmed att göra en jämförelse kring refaktorisering av teknisk skuld i olika branscher som utvecklar mjukvara. Frågeställningar som legat till grund för arbetet:

RQ1: Vilka faktorer avgör om och när det är lämpligt att göra en refaktorisering av teknisk skuld i utvecklingsprojekt inom industribolag? 

RQ2: Vilka faktorer avgör om och när det är lämpligt att göra en refaktorisering av teknisk skuld i utvecklingsprojekt inom mjukvaruföretag? 

RQ3: Hur skiljer sig argumentationerna mellan branscherna för refaktorisering av den tekniska skulden?

1.3 Avgränsningar

För att svara på de givna frågeställningarna kommer sex stycken företag som utvecklar/förvaltar mjukvara att undersökas. Hälften är från industribranschen och den andra hälften är från mjukvarubranschen. Denna studie innefattar ett fåtal

(11)

deltagare, mer energi läggs på att söka förståelse kring informanternas tankar och åsikter kring deras upplevelser av teknisk skuld.

(12)

2 Teoretiskt perspektiv

Detta kapitel ger förklaringar av begrepp som används under rapporten. Ytterligare förtydligas vad teknisk skuld innefattar, för att sedan presentera teoretiska ramverket

“Technical Debt Quadrant” samt en ontologisk mappning över typer av skulder.

Detta kommer att beaktas vid analysering av resultatet och vara en bidragande invändning till diskussionen.

2.1 Begreppsförklaring

Nedan kommer återkommande begrepp och nyckelord i denna uppsats att definieras.

Industribranschen - definieras som en grupp företag som “i vid bemärkelse ‘framställning av produkter genom förädling av råvaror’.” (NE u.å). Industriföretagen har som primär uppgift att producera produkter, och kan använda sig av informationssystem för att stödja denna process.

Exempelvis ett ERP-system eller inbäddade system i industriprodukter.

Mjukvarubranschen - definieras som en grupp företag som har ett primärt affärsmål att utveckla och publicera mjukvara till företag eller samhället. Exempel på produkt kan vara ett bokföringssystem eller att en konsult blir inhyrd för att utveckla ett program åt/med ett företag.

Faktor - är en företeelse som kan påverka något. I denna studie kan en faktor exempelvis vara element som kan skapa, förhindra eller försena utvecklingsaktiviteter.

2.2 Innebörden av teknisk skuld

För att förstå hur teknisk skuld skall hanteras, så måste det klargöras vad teknisk skuld innebär i praktiken. Kruchten, Nord och Ozkaya (2012) bidrog med ett förtydligande, där teknisk skuld särskiljs från det som användare/kunden ser och istället lägger fasta på det som utvecklarna ser. Element som nya eller tillagda funktionaliteter samt synliga buggar och låg extern kvalité anses inte som teknisk skuld utan istället det som oftast är osynligt för användarna, se figur 1.

(13)

Figur 1. The Technical Debt Landscape. Kruchten, Nord och Ozkaya (2012).

Enligt Li, Avgeriou och Liang (2015) finns det fler uttalade aktiviteter för att hantera teknisk skuld. En systematisk litteraturstudie genomfördes där de tog fram ett antal aktiviteter för att fastslå samt åtgärda fel i ett system. Ett av dessa är ”återbetalning”

och inom denna aktivitet finns en kategori som kallas för “refaktorisering”, det är denna kategori som studeras i denna kandidatuppsats.

2.2.1 Refaktorisering

Refaktorisering är principen att förändra systemet utan att ändra kodens externa/visuella beteende genom att endast göra förbättringar av den interna strukturen. Det ses som ett disciplinerat sätt att städa upp kod, för att minimera att buggar uppstår (Fowler, Beck, Brant, Opdyke & Roberts 1999). Det är det mest förekommande verktyget som utvecklare arbetar med, baserat på kod-, design- eller arkitekturskulder som behöver åtgärdas (Li, Avergiou & Liang 2015).

2.3 Technical Debt Quadrant

För att belysa faktorer till om och när refaktorisering är lämpligt behöver det kartläggas på vilket sätt skulder uppstår. Argumentet för refaktorisering kan vara annorlunda beroende på hur utvecklare tar sig an teknisk skuld, exempelvis om det sker genom bristande kompetens eller med eftertänksamhet för framtiden. Guo, Spinola och Seaman (2016) beskriver att Technical Debt Quadrant kan vara till hjälp att identifiera orsakerna till teknisk skuld.

Robert C. Martin, en pionjär inom mjukvaruutveckling och en av grundarna till det agila manifestet, argumenterade för att stökig kod inte kunde klassas som en teknisk skuld – med andra ord ”Stökig kod är stökig kod” (Martin 2009).

Fowler (2009) byggde vidare på Martinsuttalande och förde en diskussion kring att en brist i designen inte skulle bekräfta om det var en teknisk skuld som uppstått.

Istället bekräftades det genom att visa på vad som gjorde att skulden uppstod från början (2009). Detta illustrerade Fowler med en kvadrant med skiljelinjer för att visa hur skulder kunde uppstå i mjukvaruutvecklingsprojekt. Den första skiljelinjen var

(14)

om skulden som uppstod var vårdslös eller genomtänkt (visas genom Y-axeln, se figur 2). Den andra skiljelinjen var om skulden var avsiktlig eller oavsiktlig (visas genom X-axeln, se figur 2).

Figur 2. Technical Debt Quadrant. Martin Fowler (2009).

2.3.1 Sammanslagning av faktorer i ramverket

Vårdslöst och avsiktligt

Trumler och Paulisch (2016) hävdar att vårdslös skuld ofta skapas av att funktioner och design inte är tillräckligt detaljerade från produktägaren eller arkitekten.

Resultatet kan bli att utvecklaren gör sin egen tolkning över hur en implementation ska se ut, istället för att produktägaren tydliggör hur kravet ska implementeras i systemet. För att detta ska kunna undvikas måste en gemensam förståelse mellan utvecklingsteamet och produktägaren finnas.

Konsekvensen av bristande förståelse för kraven blir att hanteringen blir bristfällig och genvägar skapas av utvecklingsteamet själva (Codabux, Willams, Bradshaw &

Cantor 2017). Detta kan leda till att den potentiella lösningen inte alltid tillfredsställer kundens behov (Trumler & Paulisch 2016).

Faktorer som planering att återbetala skulden, beräkna vilka konsekvenser som beslutet kan få, samt eftertanke kring att försöka minska skadan om beslutet får förödande konsekvenser längre fram ignoreras. En vanlig konsekvens är att det leder till utdragna återbetalningar av räntan på skulden och denna typ av skuld är den som kostar mest att åtgärda (Devopedia; DevOpsGroup 2020).

Vårdslöst och oavsiktligt

Trumler och Paulisch (2016) beskriver vårdslös och oavsiktlig skuld genom att ge exempel på att en utvecklare får en order på att utveckla en funktion som utvecklaren inte har en full förståelse för. Den utbildade och noggranna utvecklaren hade tagit kontakt med produktägaren för att få full förståelse för funktionen. Ofta händer det

(15)

dock att utvecklaren väljer att inte kontakta produktägaren utan utvecklar funktionen efter sin tolkning, som utvecklaren tror är rätt, men i själva verket är fel.

Vårdslös och oavsiktlig skuld kan även uppstå när utvecklare bör veta bättre när det kommer till exempelvis objekt-orientering (Devopedia 2020). Detta leder till att kod blir producerad av utvecklare som visar inkompetens eller ignorans inför bra praxis, vilket kan resultera i programvara som visar oförväntade beteenden och sämre hållbarhet (Codabux et al. 2017).

Genomtänkt och avsiktligt

En avsiktlig skuld kan definieras som ett beslut som tas med omtanke och eftertänksamhet inför framtiden, där utvecklare är medvetna om bra design-principer men tar sig an en teknisk skuld eftersom de estimerar att räntan på skulden de producerar är relativt liten. De analyserar situationen och väljer att acceptera att det blir en teknisk skuld, om den är överkomlig (DevOpsGroup 2020).

Genomtänkt och avsiktlig skuld anses som den minst kritiska delen av kvadranten för beslutet tas medvetet, skulden kan i sin tur lagras i backloggen för att städas upp vid ett senare tillfälle. På så sätt kan produktägaren lättare reglera vilken tidpunkt som produkten är redo att levereras till kund (Trumler & Paulisch 2016).

Genomtänkt och oavsiktligt

Utvecklare producerar kod, som i efterhand kommer till insikt om att det kunde ha skrivits på ett annat sätt. System utvecklas hela tiden och utvecklare vill hela tiden lära sig och förbättra det som produceras (Devopedia 2020). Oavsiktlig skuld är av allt att döma omöjligt att undvika, då det är svårt att förutse en skuld i systemet som vid tillfället är okänd och inte är ett problem för stunden. Detta kan inte ses förrän i efterhand med en nyskapad erfarenhet, mängden skuld av denna typ kan begränsas för framtida refaktoriseringar och designförändringar (Trumler & Paulisch 2016).

Med hjälp av kravtekniker såsom “Specification by Example” kan funktioner och dess funktionalitet kartläggas under olika förhållanden och scenarion. Detta brukar leda till ytterligare förklarande frågor om systemet och en mer ömsesidig förståelse bland de involverade parterna. På detta vis minskar risken att kunna missuppfatta eller missa viktiga funktionalitet eller designfrågor (Trumler & Paulisch 2016).

2.4 Klassificering av teknisk skuld

Technical Debt Quadrant har varit vetenskapligt erkänd och använts som ett verktyg för studier inom teknisk skuld. Alves, Ribeiro, Caires, Mendes och Spínola (2014) studerade kvadranten och konstaterade att det även måste lyftas vilken typ av skuld som uppstått. Det räcker alltså inte att enbart titta på om en skuld är avsiktlig/oavsiktlig samt vårdslös/genomtänkt som Fowler tidigare illustrerat.

Alves et al. (2014) menar även att i forskning om teknisk skuld, är faktorer och indikationer dåligt organiserade och utspridda. Det försvårar skapandet av ett gemensamt “språk” om ämnet (2014). Vad de har gjort i sin studie är att de genom en systematisk litteratur-mappning definierat typer av skulder och klassificerat dessa

(16)

utifrån vad för typ av aktiviteter som föranledde att en skuld introducerades. De flesta typer av skuld hade olika indikationer som bidrog till att en skuld kunde definieras vid varje enskild typ. Alves et al. (2014) menar att den ontologiska mappningen bidrog till ett mer “sammanhållet landskap” inom teknisk skuld och gör det lättare för forskare att studera vidare inom detta ämne när de har ett gemensamt ordförråd.

Alves et al. (2014) presenterar sin sammanställning i tabellform där varje typ kopplas ihop med en definition för att få en helhetsbild över vad som föranleder att teknisk skuld uppstår med en kortare beskrivning:

Arkitektonisk skuld

Problem som uppstår i projektets arkitektur, vilket kan påverka element som effektivitet, robusthet, snabbhet etc. Tar normalt sett längre tid att åtgärda, vilket kräver mycket resurser.

Byggskuld

Problem som uppstår när funktioner i mjukvaran kräver mer onödig tid/process- hantering. Kan bestå av kompilerad kod som är helt onödig för kunden, vilket kan leda till att processen blir mer långsam än vad den behöver.

Kodskuld

Problem i källkoden som leder till att det negativt kan påverka tydligheten som i sin tur kan bidra till att det blir svårare att underhålla. Ofta beror det på dålig kodningspraxis.

Defektskuld

Typ av skuld som vanligtvis identifieras vid testning av en process, kan bestå både av kända och okända buggar. På grund av andra prioriteringar eller bristande resurser leder denna typ av skuld till att den kan åtgärdas vid ett senare tillfälle.

Designskuld

Upptäcks genom att analysera kod och likställa den med “bästa praxis”, som kod bör struktureras efter. Dålig designad kod relaterar ofta till dålig objekt-orientering och kan ses som brott mot bra praxis.

Dokumentationsskuld

Denna typ handlar om bristande dokumentation för systemet, kan vara processer där information saknas, är otydlig eller är ofullständig.

Infrastrukturskuld

Handlar om organisatoriska element som kan förhindra eller försena utvecklingsaktiviteter, exempelvis uppgradering av hårdvara som har blivit försenad.

(17)

Resursskuld

Handlar om resursfråga inom organisationen. Exempelvis att det inte finns tillräcklig med expertis internt inom företagen eller resursbrist för att åtgärda skulder som finns i ett system.

Processkuld

Processer inom system är ineffektiva, t.ex. att en funktion var menad att hantera en process på ett specifikt sätt men som nu inte längre utför det som den borde.

Kravskuld

Denna skuld handlar om avvägningar som har gjorts till kraven som har förmedlats till utvecklingsteamet, exempelvis vad som ska implementeras och hur det ska genomföras. Det kan handla om delvis implementerade krav, krav som inte är generella för alla användarfall, samt krav som inte uppfyller alla icke-funktionella krav.

Serviceskuld

Utbyte av exempelvis webb-tjänster internt inom projekt eller företag kan medföra att det introduceras en teknisk skuld, ett utbyte kan göras av affärsmässiga eller tekniska anledningar. Integrationen av den nya tjänsten måste då hanteras och anpassas så att det leder från att vara en brist till att generera värde för organisationen.

Test-automatiseringsskuld

Detta förekommer när automatisering av tester för utvecklade funktioner inte existerar. Därav minskar effektiviteten inom testningen.

Testskuld

Uppkommer vid defekter inom testning av systemet, som i sin tur hämmar systemet i sig. Kan exempelvis handla om dåligt utformade tester som inte täcker de områden som bör testas, eller att vissa tester utelämnas.

2.5 Applicering av Technical Debt Quadrant

Teknisk skuld kan med hjälp av Technical Debt Quadrant bilda en bättre uppfattning över de skulder som finns, genom en modell som förklarar vad som föranledde till att en skuld uppstod från början (Fowler 2009). Som ett komplement till Technical Debt Quadrant används den ontologiska mappningen som Alves et al.

(2014) tagit fram.

Kombinationen av Technical Debt Quadrant och den ontologiska mappningen möjliggör att informationen från informanterna lättare kan kartläggas och tolkas. När det har fastslagits vilka typer av skulder som industri- och mjukvarubranschen har i sina projekt, placeras de ut i ramverket baserat på hur skulden har uppstått. På så vis skapas en överblick över vilka skulder som företagen tar sig an och på vilket sätt.

(18)

Kartläggningen möjliggör att kunna bilda en förståelse för vilka faktorer som avgör om och när refaktorisering är lämpligt samt hur argumentationerna för refaktorisering skiljer sig åt mellan branscherna.

(19)

3 Metod

Detta kapitel avser att förklara vilken ansats samt metod som används för denna studie. I kapitlet beskrivs även hur data skall insamlas, analyseras och upprätthålla reabilitet och validitet. Till sist ses de etiska aspekterna som behöver tas i beaktande för studien över.

3.1 Vetenskaplig ansats

Filosofiska utgångspunkten med studien var att söka förståelse kring individers synvinkel på den värld som de lever i. Människor utvecklar olika subjektiva värderingar kring element och fenomen, vilket leder till att undersökarna söker efter komplexiteten i deltagarnas erfarenheter snarare än att smala av förståelsen i några få idéer eller kategorier. Målet med studien var att lita så mycket som möjligt på deltagarnas synvinkel i förhållande till det som undersöks (Cresswell 2014).

Utifrån studiens frågeställningar används en kvalitativ metod. Jacobsen (2002) menar att en kvalitativ metod är bäst lämpad när undersökaren vill ha en tydligare bild över vad som ligger bakom ett begrepp eller ett fenomen. Cresswell (2014) påpekar även att avsikten är att tolka hur andra människor ser på världen. Istället för att utgå från en teori som ofta görs i en positivistisk syn, så utvecklas teorier eller mönster genom ett induktivt synsätt.

Med den kvalitativa ansatsen tillämpades fallstudier som designmetod. Upplägget var avsett att få fram hur människor tolkade en given situation och gå mer in på djupet kring företeelsen (Cresswell 2014). Upplägget låg i linje med syftet av denna studie, att belysa faktorer samt argument om refaktorisering vid olika tillfällen och branscher.

3.2 Insamling av data

Med hjälp av en kvalitativ ansats fanns möjligheten att använda semistrukturerade intervjuer som datainsamlingsmetod, vilket i denna studie ansågs vara den optimala metoden för att införskaffa så nyanserad och rik information som möjligt för att besvara de givna frågeställningarna. För att tillgodose att en bra struktur för intervjuerna finns, så skapades en intervjuguide. Jacobsen (2015) beskriver att det är viktigt att säkerställa att de viktiga teman diskuteras. Cresswell (2014) hävdar att ju mer öppna intervjuerna är desto bättre, då författarna mer noggrant lyssnar på vad människor säger beroende på sin situation.

Individer inom olika branscher kan presentera olika bilder kring teknisk skuld, och som en potentiell konsekvens ger oss som undersökare negativa bilder kring sin arbetsplats. Därför valde vi att hålla enskilda intervjuer så att informanten kan ge en så öppen bild som möjligt kring faktorer samt när de anser att det lämpar sig att refaktorisera utifrån sina förutsättningar.

(20)

3.2.1 Urval

För att kunna uppnå syftet var det viktigt att det fanns ett strategiskt urval.

Frågeställningarna baserades på att erhålla insikter från både industri- och mjukvarubranschen. Jacobsen (2002) menar att urvalet ska baseras på avsikten med studien, för den information som efterfrågas.

Urvalet bestod av informanter som uppfyller ett antal satta kriterier. Dessa kriterier bestod av att informanten ska arbeta/ har arbetat med mjukvaruutveckling (1), informanten skall ha några års erfarenhet av utveckling i team (2), informanten ska ha arbetat inom mjukvarubranschen eller industribranschen (3). Urvalet medför att det kan säkerställas att den rätta gruppen intervjuas.

Sex stycken informanter valdes ut, där ena hälften arbetade inom industribranschen och den andra hälften arbetade inom mjukvarubranschen. Tabell 1 visar vilken bransch som varje informant representerar för att kunna tydliggöra när resultatet presenteras.

Tabell 1. Översikt över informanter

Namn Bransch Datum Typ

I1 Mjukvarubranschen 2021-02-23

kl. 17.00

Digitalt möte via Zoom

kl. 9.00

I3 Industribranschen 2021-03-04

kl. 9.00

kl. 15.35

kl. 17.00

3.2.2 Intervjuer

Data samlades in med hjälp av semistrukturerade intervjuer som spelades in och därefter transkriberades. Intervjufrågorna togs fram baserat på tidigare forskning (avsnitt 1.1), syftet med undersökningen (avsnitt 1.2) samt de teoretiska perspektiven (avsnitt 2.2 samt 2.3). Därefter strukturerades en intervjuguide upp med huvudsakliga frågor med teman som är av intresse för vår studie, se bilaga 2.

Intervjuerna genomfördes med digitala möten via ”Zoom” på grund av de rådande omständigheterna kring Covid-19, för att inte riskera att någon part blev smittad. Om förhållandena hade varit normala hade intervjuerna i stor utsträckning genomförts på informantens arbetsplats, för att göra det så bekvämt för hen som möjligt. Jacobsen (2002) menar att personer verkar ha lättare att kunna prata kring känsliga ämnen när intervjun sker ansikte mot ansikte.

(21)

3.3 Analys

En tematisk analys tillämpades för att skapa en struktur över hur den insamlade empirin skall bearbetas. Tematisk analys är en metod som används för att hitta mönster i data, med hjälp av identifiering och analysering. Detta medför att informationen organiseras och ger en mer detaljrik beskrivning av den datamängd som samlats in (Braun & Clarke 2006).

Som första steg transkriberades alla intervjuer som genomfördes för att tydliggöra allt som sades av informanten. Transkribering reducerar komplexiteten genom att mer tydligt illustrera vilken information som lämnats ut. Detta förenklade struktureringen av data som samlats in. En annan fördel är att det blir enkelt att kunna kommentera och markera begrepp som är centrala för vår studie (Jacobsen 2002; Jacobsen 2015).

Nästa steg var att skapa sub-koder för att kunna tematisera data, baserat på utdrag och att iterativt gå i genom den insamlade datamängden. Denna process förtydligar att jobba iterativt mellan sub-koder och datamängden tills en extensiv mängd teman skapats att utgå ifrån (Cresswell 2014). Teman baseras på viktig information från datamängden i relation till frågeställningarna (Braun & Clarke 2006).

Tematiseringen som är baserad på informantens svar, sattes sedan i korrelation med Technical Debt Quadrant (tabell 1, avsnitt 2.2) och klassificering av typer av skuld (tabell 2, avsnitt 2.3). Det blev härmed enklare att kunna belysa faktorer (RQ1 &

RQ2) samt hur argumentationerna för refaktorisering skiljer sig åt mellan de olika branscherna (RQ3).

3.4 Reliabilitet och validitet

Med god reliabilitet och validitet menas att den data som undersökarna införskaffar är tillförlitlig och giltig/relevant för undersökningen (Jacobsen 2002).

För att upprätthålla validiteten valdes informanter ut genom ett strategiskt urval. Detta för att säkerställa att informanterna som valdes ut hade tillräckligt med erfarenhet och kunskap för att kunna besvara de semistrukturerade intervjufrågorna, vilket konstruerats utifrån frågeställningarna och de teoretiska ramverken. Jacobsen (2015) hävdar att information från flera oberoende källor ger högre giltighet vid beskrivning av fenomenet (2015), därav valdes tre informanter från varje bransch.

Det skickades ut “huvudfrågor” till informanterna för att låta dem bli införstådda med vad som efterfrågades och kunna förbereda sina svar i viss mån. Baserat på informanternas svar, formulerades följdfrågor i förhoppning om att få oförberedda svar. Kommer information spontant från informanten, ökar chansen för giltighet (Jacobsen 2015).

Intervjuerna spelades in för att underlätta transkriberingen. I studien tillfrågades informanterna om de ville ta del av materialet och säkerställa att personen hade blivit rätt återgiven. Då möjligheten fanns att informanten formulerade sig fel kunde de då ändra sitt svar till ett mer korrekt alternativ.

(22)

För att öka reliabiliteten hölls informanternas namn och deras företag konfidentiellt.

Detta för att informanten inte skulle känna sig orolig för att säga vad hen tänkte och tyckte. Jacobsen (2015) hävdar att många informanter inte vill svara på frågor, då de är rädda att svaren kan kopplas till personen i fråga och dess åsikter.

Enligt Jacobsen (2015) påverkas alltid undersöknings-objektet av olika faktorer i en undersökning. Det kan exempelvis vara av intervjuaren eller miljön som

informanten befinner sig i (2015). För att minimera denna effekt skedde intervjuerna över Zoom. Detta gjorde att informanten själv kunde välja en miljö som hen trivdes i.

3.5 Etiska överväganden

Etiska överväganden har tagits i beaktande i vår studie, baserat på tre grundläggande krav som undersökningen borde uppfylla (Jacobsen 2002).

Det första kravet är informerat samtycke, där togs det i beaktande att den som undersöks är helt frivillig i sitt deltagande. I informationsbrevet (se bilaga 1) uttrycktes det explicit att informanten självmant valde att delta i undersökningen samt att hen hade full rätt att avbryta sitt deltagande om så önskas. De fick även en mer detaljerad bild kring undersökningens syfte, hur intervjuerna skulle gå till och hur allt material skulle hanteras. Informanterna får då enligt Jacobsen (2015) en klarare bild över vad deras information har för mening och vad målsättningen är med att använda deras uttalande kring ämnen för studien.

Den andra aspekten är rätten till privatliv, det som hafts i åtanke där är att informationen som samlas in inte kunde knytas till enskilda individer eller dess arbetsplatser, då risken finns att svar kan knytas till en specifik individ och kan skapa problem för densamma (Jacobsen 2015). Öppenhet kring svaren som samlades in var av stor vikt, därför kommer inga namn på individer eller företagsnamn att uppges någon gång i processen, för att skydda alla informanters integritet. Allt material som samlades in från informanterna kommer att lagras på lösenordskyddade datorer, för att kunna säkerställa att ingen obehörig ska kunna få tillgång till inspelningarna som genomförts vid alla intervjuer. Detta avser principer för GDPR som att samla in personuppgifter för särskilda ändamål samt att skydda uppgifterna så att inte någon obehörig får tillgång till dem. (Integritetsmyndigheten u.å).

Till sist fanns kravet på korrekt presentation av data, vilket syftar till resultat ska återges fullständigt och i dess rätta kontext (Jacobsen 2015). För att säkerställa detta, ställdes frågan vid varje enskild intervju om informanten önskade att läsa i genom transkriberingen i efterhand ifall det fanns punkter som inte stämde överens, eller element som tolkats fel och behöver revideras. Detta för att säkerställa att data inte manipulerats, antingen av felcitering eller utdrag som sätts i fel sammanhang.

(23)

4 Resultat

I följande kapitel presenteras det empiriska resultatet som undersökningen gav baserat på de intervjuer som genomförts med informanterna. Sammanställningen av resultatet är upplagt efter de teman och sub-koder som påträffats. Dessa har delats in efter bransch, för att enklare kunna visualisera resultatet.

4.1 Teman

Baserat på resultatet som samlats in vid undersökningen, har ett antal teman funnits.

Dessa teman delas in för varje bransch och har ett antal sub-koder som plockats ut vid djupare analysering av materialet. Tabellen nedan illustrerar dessa teman och dess sub-koder.

Tabell 2. Teman och sub-koder

Teman Sub-koder Bransch

Typer av teknisk skuld

Kod- och designskuld Arkitektskuld Process- och serviceskuld

Industri Arkitekt- och designskuld

Process- och kravskuld Resurs- och kodskuld

Mjukvara

Faktorer för refaktorisering

Förändringsbenägenhet Resurser Testning Storlek & konsekvens

Industri Ekonomi, livscykel & konsekvens

Tillfredställande Storlek

Mjukvara

Tidpunkt för refaktorisering

Prioritering

Industri Situationsberoende

Resurser

Mjukvara

Strategi

Dokumentation Förebyggande

Industri Dokumentation

Beslutsfattande

Mjukvara

4.2 Typer av teknisk skuld

I temat “typer av teknisk skuld” beskrivs olika varianter av teknisk skuld företaget tagit sig an eller upptäckt. Temat går även in på hur den tekniska skulden har uppstått.

I samtliga intervjuer hittades tydliga samband mellan vilka typer av skulder som fanns inom mjukvaruprojekten. De tydligaste exemplen som var gemensamma hos

(24)

informanterna var kod-, arkitekt- och process-skuld.

Kod- och designskuld

En informant menade att kodskuld kunde uppstå som en konsekvens av att utvecklare hade skrivit otydlig kod som var oläslig för nästa person som skulle arbeta med koden.

En annan informant menar att utvecklare tar medvetna val att ta sig an kod- och designskuld, av olika anledningar. Informanter belyste situationer som att ta en kortare väg för att komma vidare i arbetet eller att resursbrist bidrog till att bristande lösningar behövde vidtas, som hårdkodning

”Det är avvägningar hela tiden, ibland får vi välja ”fullösningen”, det får duga nu - vi bygger om det sen.”

(Informant 3) Arkitektskuld

Informanterna påpekade att mycket av utveckling idag är en löpande process och det kan uppstå nya krav som kan komma från kund eller från andra parter inom organisationen. Nya krav medför att systemen snabbt måste utvecklas för att stödja nya funktioner. I kombination med ovanstående var faktorer som framtida förändringar som det inte togs höjd för samt att prioritering av leverans till kund kom före att göra implementationen optimalt, stora delar som bidrog till att systemen fick teknisk skuld. Vid arkitektskuld i ett system måste avvägningar vidtas på sikt om den tekniska skulden ska åtgärdas eller byggas på. En informant klargjorde problematiken tydligt och förklarade vikten av att försöka åtgärda strukturen på systemet på arkitektnivå:

“Vi har ett projekt där jag jobbade och vi insåg - sen kan man diskutera om det var teknisk skuld eller något annat vi såg, men att en större omdesign skulle gynna oss i längden. Och då är det inte så att vi la tid bara för att göra en bättre mjukvara som ser snyggare ut, utan vi la tiden som en investeringstid för att vi såg att på lång sikt skulle det här bli bättre och spara tid.”

(Informant 5) Process- och serviceskuld

Processförändringar var en annan typ av skuld som samtliga av informanterna uppgav var vanligt. De belyste att det sällan är utvecklarna som producerar skulderna.

Skulderna uppkommer istället vid utbyte av tjänster i system eller vid processförändringar i produktionen, vilket det nuvarande systemet inte var anpassat till. Majoriteten av informanterna uppgav även att det inte alltid var helt klart om hur de nya funktionerna för processförändringarna skulle se ut, utan de fick själva tolka hur implementationen skulle göras. En informant beskrev kortfattat händelseförloppet vid process-skuld:

(25)

“Kanske det har varit processändringar inom organisationen och sådana saker, då har du kanske en applikation som stödjer den processen bara och sen ska man göra man förändringar så blir det

väldigt svårt och kanske skruvar till det hej vilt…”

(Informant 4) Skulder vid utbyte av tjänster kunde förekomma ifall ett system skulle uppgraderas med nyare mjukvara och då kunde utvecklare aktivt bygga på serviceskuld i en övergångsperiod, i syfte att köpa tid för sig själva och inte påverka användarna utåt.

Inom mjukvarubranschen lades större fokus på kunden i fråga. Kunden styr ofta förutsättningarna för projektet och det läggs mycket energi på att leverera produkter inom tidsramar. Därför valdes här ofta avsiktligt att ta sig an teknisk skuld för att möta sina tidsramar och tillfredsställa kunderna.

Arkitekt- och designskuld

Arkitektonisk skuld nämnde samtliga informanter var ett återkommande problem. Det kunde uppkomma vid bristande förståelse för kundens krav samt ovisshet kring hur system skulle struktureras på ett optimalt sätt. Flera informanter gav exempel på att arkitekt- och designskuld kunde uppstå som en konsekvens av att vilja nå milstolpar och leverera till kund i tid, vilket prioriteras över att analysera och bygga system med optimal kvalité.

“Vi levererar ett fullt fungerande system, men vi upplevde att det blir mer och mer tungt rodd. Och oavsett när vi hade tagit beslutet av att refaktorisera, så hade det varit bättre att ha tagit beslutet. Vi sa att vi hade kommit så långt nu så, det är så lite kvar och det kostar för mycket att backa för att tjäna in kvalitén.”

(Informant 1)

Även uppdateringar för olika ramverk var en faktor som bidrog till att arkitekt- och designskuld uppstod, det kunde handla om att ett system använde en viss version av ett ramverk som vid ett senare tillfälle behövde skrivas om. En av informanterna nämnde att det även fanns fall där plugins som användes behövde bytas ut efter en viss tid vilket kunde leda till potentiellt problem för systemet. Förändring av strukturen kunde därmed behöva anpassas och refaktoriseras för ramverkets fortsatta fungerande i systemet.

Process- och kravskuld

Kunderna kunde komma med nya krav för sitt system som behövdes implementeras.

Vissa informanter beskrev att detta var någonting som ofta bidrog till att systemen fick teknisk skuld i form av process- & kravskuld, dvs. att funktioner som redan fanns i systemen inte längre genomförde det som det var avsett att göra. Fenomenet var

(26)

något som var oförutsägbart och det var svårt att avväga hur skulden skulle hanteras.

Anledningen till det var att företag vill göra kunden tillfreds för att främja sig själva och sitt rykte.

”Många gånger är förändring av krav under projektets gång orsaken till teknisk skuld, och vill man vinna en upphandling så har man inte möjlighet att lägga på kostnader för det”.

(Informant 1)

Resurs- och kodskuld

Problemet när företag står inför sin tekniska skuld och åtgärder behöver sättas in, då finns sällan resurserna att tillhandahålla - i form av tid, pengar och arbetskraft. I dessa fall var kodskuld vanligt. Informanterna var överens om att på grund av diverse anledningar löser de en situation genom att generera snabba lösningar, som på sikt inte är hållbart men som är det mest realistiska för tillfället. Ett exempel kan vara kompetensnivån hos utvecklarna, där ingen skriver likadant som den andra.

Resursfrågan kunde leda till att bristande kod produceras och i förlängningen bidrar till problem i systemet.

“Det kan vara en sådan typ av skuld att man märker att koden inte ser ut att vara på ett optimalt sätt, och den kan vara olika kompetensnivåer.

Olika utvecklare skriver olika kod, och hur noggranna de är osv, Det kan vara någon programmerare som löser det med 50 rader kod medan någon löser det med 30 rader.”

(Informant 2)

4.3 Faktorer för refaktorisering

Temat avser att beskriva de faktorer som företagen har i beaktande när en teknisk skuld bör eller ska refaktoriseras. Faktorer som antingen kan förhindra eller försvåra refaktorisering tas även upp här.

Inom industrierna fanns det olika faktorer som avgjorde om en refaktorisering av kod skulle genomföras.

Förändringsbenägenhet

Informanterna argumenterade med systemet i fokus, dvs. att de ofta tog i beaktande hur pass förändringsbenägen en del av systemet var. Argumentationerna bakom det var att om det sågs ett behov att vidareutveckla en applikation och teknisk skuld låg i bakgrunden och gömde sig, så var de mer benägna att attackera det och åtgärda under tiden de arbetade med de uppdrag de hade planerat. En av informanterna menade att teknisk skuld kunde leda till mycket branchning i koden, att det leder till sidospår i

(27)

utvecklingen istället för att lösa uppdragen som de fått tilldelat sig. Refaktorisering blir då en viktig del i det dagliga arbetet.

Resurser

Andra faktorer som även togs upp var resurser i form av mantimmar som det tar att åtgärda skulden och som finns tillgängliga. Olika typer av skulder tog olika lång tid att refaktorisera. En informant klargjorde vad det kunde leda till i det dagliga arbetet:

”Resurser spelar helt klart in. Vi har en slimmad organisation, man har inte oändliga resurser och då måste man tyvärr prioritera där. Vår tekniska skuld – mot kundens eller fabrikens eller företagets krav på IT- avdelningen…”

(Informant 3) Testning

Testning av en funktionalitet var också en aspekt av arbetet. Ställs det höga krav på att funktionaliteten gör vad som är avsedd med den, då bidrar det med en stor indikator till att det ska refaktoriseras:

“Det kan vara så, vi har vissa delar utav företaget som utvecklar [...]

mjukvara och sådan process har väldigt höga krav på testerna... och då kan det vara så att vi kan behöva göra något för att kunna uppnå det här, och det är på en ganska detaljerad nivå."

(Informant 5) Storlek och konsekvens

Ett annat tema som diskuterades var ifall storleken av den tekniska skulden spelade någon roll när en refaktorisering ska eller bör genomföras. Informanterna uppgav olika ståndpunkter angående detta. Informanterna var dock likasinnade när det handlade om vilka konsekvenser som skulden medförde till systemet, samt om en del av systemet var förändringsbenägen dvs. om det skulle vidareutvecklas. Däremot var de oense om huruvida storleken spelade roll. Majoriteten av informanterna menade att om en skuld var relativt liten var de mer villiga att refaktorisera då det ofta krävdes mindre resurser för att åtgärda det. Däremot hävdade en annan informant att det var svårt att argumentera för att lägga pengar på att refaktorisera en liten teknisk skuld, som kanske inte alls har någon större påverkan på systemet.

Samtliga inom mjukvarubranschen argumenterade för vilka faktorer som spelade in om en refaktorisering bör ske.

Ekonomi, livscykel och konsekvens

De ekonomiska konsekvenserna spelade en stor roll kring huruvida refaktorisering var nödvändigt eller inte. Argumentet bakom var att förvaltningskostnaderna över systemets förväntade livslängd hade en avgörande roll. Informanterna menade att det

(28)

kunde vara svårt att förvalta ett system som innehöll mycket teknisk skuld. Åtskilliga timmar av arbete kunde krävas för att göra uppdateringar i system med bristande struktur. Hade skulden små konsekvenser på förvaltningen, så lät de oftast skulden ligga kvar för att det inte fanns någon ekonomisk vinning i att refaktorisera.

”Håller man på med förvaltning är också refaktorisering av kod väldigt kostsamt för det innebär att man måste få testa väldigt mycket av det refaktoriserade.”

(Informant 1) Om ett projekt hade en längre livscykel, så påpekade en informant att teknisk skuld skulle undvikas. Framförallt i tidigt skede av projektet. Det var viktigt att bygga en stabil grund, så att eventuella framtida refaktoriseringar inte innebar att hela systemet behövde skrivas om. Handlade det däremot om projekt som fungerade som pilot-projekt så lät de oftast den tekniska skulden vara.

Tillfredställande

Informanterna kunde även argumentera för om det var uppenbart att det fanns brister i systemet och det var synligt för kunden, så var de mer villiga att lägga resurser på att kunden får ett stabilare och bättre system än att de lägger tid för nya funktionaliteter. Det var viktigt att främja företagets rykte och visa att man höll god kvalité.

”Är det uppenbart att systemet har en sämre prestanda på grund av att vi har skrivit dålig kod? När det gäller kunden så måste vi ta tag i detta, och kanske inte lägga alla resurser på en ny häftig feature, utan att kunden får ett stabilare och bättre system.”

(Informant 2) Det fanns även argumentation för att prioriteringar var en stor faktor. Skulle det vara så att en milstolpe var inom räckhåll, och ett problem hittades, så kunde teamet avväga och välja att inte refaktorisera. Situationen som uppstod i relation till målsättningen för systemet var en stor bidragande faktor till om det var lämpligt att refaktorisera. Skulle det dock vara så att skulden blir alldeles för stor, så hanteras det därefter.

Storlek

När det kom till att refaktorisera diskuterades betydelsen av den tekniska skuldens storlek. Olika ståndpunkter gavs från informanterna, många gånger var det lönsamt för företagen att åtgärda skulder som var av mindre karaktär och enklare typer.

Informanter menade att många små och enkla refaktoriseringar kunde eliminera stora refaktoriseringar på sikt. Dessa små refaktoriseringar var även lättare att få in i den befintliga budgeten.

En annan informant menade att om storleken på skulden var för stor och krävde stora resurser för att åtgärda, försökte de “leva” med skulden men anpassa den istället.

(29)

“Man kommer till den tidpunkten med att man funderar på att man kanske vill göra så lite som möjligt, sen kräver kunden att man gör uppdateringar på ett gammalt system för att det kommer nya regelverk och saker som styr. Och systemet måste vara funktionsdugligt.”

(Informant 2)

4.4 Tidpunkt för refaktorisering

Följande tema beskriver vid vilken tidpunkt företagen refaktoriserar sina system efter att ett beslut om refaktorisering är taget.

Prioritering

Samtliga informanter menade att om ett team skall ändra en del av ett system och det finns behov av refaktorisering av en teknisk skuld i just den specifika delen, då löser de skulden i samband med att den nya förändringen implementeras. Argumentet bakom var att det ofta handlade om prioriteringsfrågor. Andra uppgifter ansågs vara viktigare än att lägga ner tid och pengar på att refaktorisera stora delar av systemet.

Kompromissen enligt en informant var att smyga med refaktoriseringen i planeringen i samband med utveckling av ny funktionalitet.

“Vissa av dessa smyger vi med i den vanliga releasecykeln för programvaran, vi ser att vi ska göra en ändring i den här delen av koden – ja då har vi den här tekniska skulden och då tar vi med den… Det är nästan det enda sättet för vi kommer aldrig få resurser eller pengar att ta hand om alla ”tickets” som är teknisk skuld.”

(Informant 3)

En annan informant var inne på samma spår, dokumentation av de tekniska skulderna som finns och dess typ gör det enklare att kunna planera när refaktorisering skulle genomföras:

“Där ser vi vilka tekniska skulder vi har tagit oss på, då har du i varje fall det på papper och när du gör din planering sen kan du titta och se att vi ska in där och göra förändringar, då kanske vi ska ta och planera in att göra den förbättringen där vi har den tekniska skulden.”

(Informant 4)

(30)

Situationsberoende och resurser

Samtliga informanter uppgav att tidpunkt för refaktorisering var situationsstyrt mellan olika projekt. En viktig aspekt var frågan, hur skulden påverkade systemet.

Visade systemanalyser att det fanns uppenbara brister, så dirigeras arbetet om från att utveckla nya funktioner till att lösa skulden. Vid allvarligare situationer spelade budgeten inte roll för att lösa problemet.

En annan aspekt som lyftes fram var de resursrelaterade faktorerna. Fanns det kapital i den ekonomiska budgeten och tillgänglig personal, så kunde refaktorisering göras mer omgående. Annars försökte de “frysa” skulden och åtgärdas vid ett bättre tillfälle.

Samtliga informanter menade att refaktorisering lättare kunde rättfärdigas ifall avkastningen för investeringen att lösa problemen var som störst.

Informanter menade att konsekvensen av att inte refaktorisera, även var en faktor för när refaktorisering genomfördes. De ville inte att problem skulle bli allt för omfattande längre fram i utvecklingsprocessen och då fick teamen göra en bedömning och diskutera vilket nästa steg som skulle tas.

”Sen får man göra bedömningen om vi fortsätter på denna vägen och inte tar tag i dessa problemen, vad innebär det? Kan det bli ännu mer refaktoriseringsjobb i framtiden, på grund av att man fortsätter, och sen måste man backa. Och då tar det lite längre tid.”

(Informant 2)

4.5 Strategi

Sista temat avser att belysa ifall företag har en uttalad strategi för hantering av den tekniska skulden och eventuell refaktorisering.

4.5.1 Industribranschen Dokumentation

Strategier för att åtgärda en teknisk skuld fanns det olika ståndpunkter kring. Några informanter hade en tydlig och klar strategi hur de skulle gå tillväga, medan andra inte hade en uttalad strategi utan det berodde helt på situationen i fråga. Men vad som var gemensamt var att när en teknisk skuld upptäcktes så skrevs det upp och dokumenterades så de åtminstone hade kännedom kring den tekniska skulden. Vid ett senare tillfälle kunde de vid planeringsfasen titta på vad för brister som fanns i systemet och göra en bedömning kring huruvida det skulle refaktoriseras eller inte.

(31)

En informant beskrev att så fort som en teknisk skuld uppdagades så dokumenterades detta och lagrades i deras backlogg:

”Vi lägger alltid in det, vi använder gira som hanteringssystem där vi använder ”tickets” för att markera en teknisk skuld.”

(Informant 3)

En annan informant förklarade vikten av att dokumentera teknisk skuld, detta specifikt över de medvetna val som tagits under utvecklingens gång

”Ibland brukar man ha ett dokument som beskriver: de här valen har vi gjort, det här har påbyggt vår tekniska skuld som man hela tiden under projekten kan gå och titta på – de här har vi som teknisk skuld som vi har medvetet tagit.”

(Informant 4)

Förebyggande

Vikten av att förebygga teknisk skuld var stor enligt en annan informant där livscykeln på projektet spelade stor roll för hur de arbetade med sin mjukvara.

Det kunde finnas specifika roller inom ett team vars syfte var att se över design och på så sätt minimera teknisk skuld. Det fanns även standarder inom utvecklingen att följa och obligatoriska testfall att kunna utföra.

“Så det vi utvecklar måste vara underhållsbart och kunna leva en längre period, till skillnad från mindre mjukvaruutvecklingsföretag, så har vi roller som är mjukvaruarkitekter som är med och granskar design som sätts och så då är, vilket gör att vi inte ska få stora arkitektuella skulder i alla fall.”

(Informant 5) 4.5.2 Mjukvarubranschen

Dokumentation

Inom denna sektor fanns en gemensam uttalad strategi för hur refaktorisering ska tillämpas. Två informanter uppgav att det fanns rutiner för hur en teknisk skuld skulle rapporteras och hanteras. Rapporteringen skedde genom att dokumentera så kallade

”improvement-tickets” så att de inte förlorades under arbetets gång. Både innan och efter refaktoriserings-processen utfärdades olika typer av tester för att säkerställa att funktionaliteten fungerade som den skulle.

En annan informant hade likande strategi med att dokumentera de tekniska skulderna som var aktuella. Dock fanns inga rutiner för att utföra refaktoriseringen eller uppföljning.

(32)

Beslutsfattande

Besluten kring refaktorisering kunde ske på olika nivåer inom organisationer som informanterna förklarade. En informant uppgav att beslutet kunde tas av en systemarkitekt, fanns inte mandatet så lyftes det högre upp i hierarkin inom organisationen. Vid mindre former av refaktorisering kan frågan och beslut hanteras på lägre nivåer mellan utvecklingsteamen själva.