Vid faktorer för refaktorisering ses skillnader mellan industrin och mjukvaruföretagen. När det kommer till industrin finns det två tydliga exempel på vad som spelade in ifall system behövde refaktoriseras, där förändringsbenägenheten och konsekvensen av skulden var avgörande faktorer. Vi ser en korrelation mellan tidigare forskning och vad som framkommit i vår studie. Sharma, Suryanarayana och Samarthyam (2015) hade belyst liknande faktorer som talar för att refaktorisera system, vilket kan förklara varför vi såg tendenser till att industribranschen hade fler genomtänkta skulder än vårdslösa. I grunden handlade det inte om att skulden skulle åtgärdas så fort den hittades, refaktorisering kunde utvecklingsteamen avvakta med så länge systemet fungerade samt att funktionen inte skulle förändras där och då. I takt med att funktioner skulle vidareutvecklas så var det av absolut vikt att refaktorisera då de inte ville riskera att göra skulderna större och på sikt göra mjukvaran ohållbar och medföra större aktiviteter för att lösa problemen.
Guo, Spínola och Seaman (2016) hävdar att refaktorisering inom mjukvarubranschen kunde beslutas efter ett antal faktorer, som kundens förväntningar, tillgängliga resurser inom utvecklingsteamet, räntan på skulden, hur statusen på de skuldinfekterade komponenterna ser ut och hur skulden påverkar andra funktionaliteter (2016). Författarna lägger mycket fokus på källkoden och dess kvalitet, vilket är en viktig del att ha i beaktande, men i jämförelse med vår studie ser vi andra tendenser som kan avgöra för refaktorisering. Resultaten som samlats in i denna studie visar att även ekonomi hade en viktig roll, då företagen satt en budget för projektet och det var viktigt att förhålla sig till den. Informanterna redogjorde för att refaktorisering är en väldigt kostsam process och därav avvägs det noggrant innan teamen tar beslut att genomföra det. Framförallt när det kommer till förvaltning av system, om skulden inte betalades tillbaka kunde problemen växa med tiden och konsekvenserna av skulden kunde bli ohållbara i längden och dyrare att refaktorisera. Fanns det uppenbara brister som akut behövde lösas, var det lämpligt att refaktorisera. Visade det sig att den tekniska skulden var oavsiktlig, spelade inte ekonomi lika stor roll om konsekvensen var stor. Företagen var då beredda på att jobba utöver den tid som hade förhandlats fram mellan parterna. Skulle det dock vara så att kunderna kommer med nya krav utöver det som förhandlats fram, kunde nya diskussioner föras.
6.3 Tidpunkt för refaktorisering
Med stöd av den insamlade empirin är tidpunkten för refaktorisering enligt industribranschen en prioriteringsfråga mellan att möta kunders krav i tid och hålla systemet så skuldfritt som möjligt. Codabux och Willams (2013) argumenterar för att ny funktionalitet i systemet inom industribranschen har större prioritet än att åtgärda
bristfällig källkod. Påståendet ovan kan delvis stödjas, vår studie bekräftade att kunden var den största prioriteten och att det var svårt för utvecklingsteamen att argumentera för att lägga resurser på att endast åtgärda teknisk skuld i systemet. Men det betydde inte att den tekniska skulden prioriterades bort i alla lägen, utan samtliga informanter menade att skulden med fördel åtgärdas tillsammans med implementationen av den nya funktionen som kunden önskar.
Mjukvarubranschen hade en annan syn på vilken tidpunkt de ansåg vara mest lämplig. Samtliga informanter ansåg att refaktorisering var situationsstyrd och att det var svårt att ge en exakt tidpunkt för när det bör genomföras. Vad som styrde situationerna mer konkret var tillgängliga resurser i form av pengar och personal, påverkan på system och hur räntan för skulden kommer att utvecklas. Tidpunkten kunde därför vara olika från situation till situation. Om refaktorisering inte var nödvändig eller att de inte såg en större ekonomisk vinning, så lät de ofta systemen vara som de är. Företagen refaktoriserade istället när det blir nödvändigt eller när avkastningen för investeringen blir högre dvs. de tjänar mer på att åtgärda problemen vid ett givet tillfälle. Här ser vi delvis en korrelation med Yli-Hummo, Maglyas och Smolanders (2016) studie som hävdar att det finns fall där mjukvarubranschen väntar med att refaktorisera tills inget annat val fanns.
6.4 Strategi
Informanterna inom industribranschen redogjorde för att teknisk skuld dokumenterades ner i backloggar och lät det vara tills vidare, anledningen var att upprätthålla vetskapen om den befintliga skulden så att den inte gick förlorad. Skulle företagen vidareutveckla en funktionalitet som var skuldbelagd så tog de med refaktoriseringen av den tekniska skulden i planeringen. Händelseförloppet kan tolkas som att det lutar åt en mer aktiv strategi, definierat av Verdecchia et al. (2021). Vikten av att förebygga teknisk skuld var enligt industribranschen viktig. Informanter beskrev att det kunde vara en fördel att ha dedikerade arbetsgrupper vars jobb är att se över design och minimera potentiella skulder som kan uppstå, vilket förutsätter att utvecklingsteamen arbetar med en god standard för hur projekten ska se ut. Hade alla företag applicerat samma strategi, skulle teknisk skuld potentiellt kunna minskas. Speciellt inom industrin, där systemen ofta har en lång livscykel och där det behövs försäkring om att teknisk skuld så gott som möjligt undviks. Sharma, Suryanarayana och Samarthyam (2015) belyste faktumet att försäkra sig om att designen och funktionaliteten inte leder till någon teknisk skuld, då resurser behöver sättas in för att åtgärda problemen.
Sätts mjukvarubranschen i jämförelse med industrin, kan vi se att mjukvarubranschen har en strategi som mer lutar åt en retro-aktiv strategi. Informanterna redogjorde för att utvecklingsteamen dokumenterade ner de skulder som fanns i systemet, men emellanåt åtgärdades inte skulderna förrän det var nödvändigt. På grund av det ökade trycket att leverera till kund kunde det beslutas om att avstå ifrån att refaktorisera, vilket ligger i linje med vad Mensah et al. (2017) beskrivit. När väl analyser genomfördes och det konstaterades att refaktorisering var nödvändigt, så kunde beslutsfattandet enligt vår studie se annorlunda ut beroende på vilket företag det
handlar om. I idealfallet kunde beslutet tas av en systemarkitekt som ofta är mest insatt i projektet men i andra fall kunde frågan lyftas högre upp i hierarkin. Med fördel så skulle det gjorts tydligt från början vem det är som ska ta besluten. Problemet med mjukvarubranschen är att det ofta är konsulter som arbetar inom den sektorn vilket leder till att beslutsfattandet kan vara svår att definiera, men även att kunderna hellre fokuserar på resultat rent visuellt före en stabil källkod som ingen kommer att synligt utifrån.
6.5 Metodreflektion
Som tidigare beskrivits implementerades en kvalitativ metod med fokus på intervjuer. Målet med studien var att söka förståelse kring hur företag inom olika branscher ser på refaktorisering och vilka faktorer och argument som ligger bakom besluten om att refaktorisera.
Metoden som valdes har varit till hjälp med att besvara frågeställningarna för studien. Med de semistrukturerade intervjuerna som utgångspunkt möjliggjordes att information från informanterna uppgavs i dess rätta kontext, vilket gjorde det mer begripligt och underlättade att kunna analysera resultatet efter de teoretiska perspektiven som redogjorts. När en situation kring teknisk skuld sattes i ett samband så byggde det en helt annan förståelse kring vilka faktorer och argumentationer som avgjorde när refaktorisering ansågs lämpligt.
Nackdelen med metoden i vår studie var att mycket har påverkats av den rådande pandemin, många företag hade inte resurser eller villighet att ställa upp vilket gjorde det problematiskt för oss att hitta informanter. Dessutom blev det svårare att genomföra intervjuerna digitalt, dels på grund av tekniska svårigheter men även genom att interaktionen mellan informanten och oss som ledde intervjuerna inte blev densamma då intervjuerna inte skedde fysiskt. Det är en annan sak att genomföra en intervju på plats och mötas ansikte mot ansikte. Jacobsen (2002) menar att personer verkar ha lättare att kunna prata kring känsliga ämnen när intervjuer sker ansikte mot ansikte.
7 Slutsats
Syftet med studien var att göra en jämförelse kring refaktorisering av teknisk skuld i olika branscher som utvecklar mjukvara. Industri- och mjukvarubranschen
undersöktes och ställdes mot varandra, för att se om det fanns olika faktorer och argumentationer för refaktorisering. Utifrån syftet konstruerades tre frågeställningar som skulle besvaras.
Efter avslutad analys och diskussion identifierades två primära avgörande faktorer för refaktorisering gällande RQ1 och RQ2:
RQ1: Vilka faktorer avgör om och när det är lämpligt att göra en refaktorisering av teknisk skuld i utvecklingsprojekt av mjukvara, enligt svenska industribolag?
Faktorer:
• Konsekvens – Avses med hur den tekniska skulden påverkar systemet i nutid och på sikt.
• Förändringsbenägenhet – Avses med ifall funktionaliteter skall vidareutvecklas längre fram och teknisk skuld finns närvarande.
Tidpunkt:
• Samband med vidareutveckling – Refaktorisering planeras in vid vidareutveckling av en befintlig funktion som har teknisk skuld.
RQ2: Vilka faktorer avgör om och när det är lämpligt att göra en refaktorisering av teknisk skuld i utvecklingsprojekt, enligt svenska mjukvaruföretag?
Faktorer:
• Konsekvens – Avses med hur den tekniska skulden påverkar systemet i nutid och på sikt.
• Ekonomi – Avses med om det finns utrymme i budgeten för att refaktorisera.
Tidpunkt:
• Situationsberoende – Utifrån vår studie går det inte att fastställa en specifik tidpunkt som mjukvarubranschen anser är den mest lämpliga för att refaktorisera. I de flesta fallen beslutar företagen för refaktorisering när avkastningen av investeringen blir som högst eller när inget annat val finns.
RQ3: Hur skiljer sig argumentationerna mellan branscherna för refaktorisering av den tekniska skulden?
Industribranschen argumenterar för att utvecklingsteamen skall fortsätta att utveckla och förvalta sina interna system under en längre tid. För att underlätta det framtida utvecklingsarbetet, prioriterar industribranschen att refaktorisera delar av systemet som har en förändringsbenägenhet. I samband med vidareutveckling av en funktion är det lättare att planera in refaktorisering, med hänsyn till tidsplanen samt budgeten.
Mjukvarubranschen argumenterar för refaktorisering mer ur ett ”Return of investment” perspektiv. Faktorn som skiljer sig från industrin är de ekonomiska förutsättningarna att genomföra refaktorisering av systemet. Företagen försöker refaktorisera vid den tidpunkt där avkastningen för refaktorisering är som högst eller när inget annat val finns. Företagen utvecklar mjukvara som sin primära verksamhet och därav är det av större intresse att utveckla mjukvara så effektivt som möjligt men samtidigt möta kundens förväntningar till attraktivt pris.