Det här examensarbetet undersöker sambandet mellan kodmåtten cyklomatisk komplexitet, antalet metoder i en klass och djup i arvshierarkin och de faktiska anledningarna till att en kodbas blev grundligt refaktorerad. Man har länge försökt använda kodmått som indikationer på hur mycket ansträngning som krävs för att förändra en kodbas när nya krav framkommer. I fallstudien tittar vi på en kodbas som refaktorerats på grund av den dåliga underhållbarheten för att utreda till vilken grad kodmåtten antyder de problem som låg till grund för refaktoreringen. Målet är att ta reda på om man kan använda kodmått som indikator på vad som bör refaktoreras när man som konsult kliver in i ett projekt med kvalitetsproblem. Metoden som används för att identifiera problemen i kodbasen är kvalitativa intervjuer, och mätvärdena hämtas ur verktyget NDepend. För att öka reproducerbarheten och validiteten i analysen kretsar intervjuerna kring definitionen av underhållbarhet ur ISO/IEC 25010. Slutsatsen är att de mått som ger väldigt höga värden på vissa klasser eller metoder ofta indikerar objekt som är involverade i större problem i kodbasen. I den här fallstudien indikerade dock måtten sällan objekt av ”rätt anledning”, alltså av den anledning som anges i litteraturen. Därför bör man inte använda kodmåttens värde som direkt indikation på objekt som ska refaktoreras, utan snarare välja att titta närmare på de objekt som indikerats och göra en professionell bedömning. Resultaten går inte helt i linje med tidigare forskning, där vanliga samband mellan kodmått och underhållbarhetsproblem sammanställts. Detta antas bero på överanvändning av lös koppling i koden som studerats. / In this thesis, the correlation of the code metrics Cyclomatic Complexity, Number of Methods in Class and Depth of Inheritance Tree with the real reasons a codebase got heavily refactored is investigated. Code metrics have long been used in a attempts to indicate the amount of effort needed to change a codebase when new requirements emerge. In the case study we look at a codebase that has been refactored due to the low maintainability, to see to which degree the code metrics imply the problems on which the decision to refactor was based. The goal is to find out whether code metrics can be used as indicators of what should be refactored when you as a consultant join a project with existing quality problems. The method used to identify the major problems in the codebase is qualitative interviews and the code metrics values are measured with the tool NDepend. To improve the reproducability and validity of the analysis, the interviews are built around the definition of maintainability presented in ISO/IEC 25010. The conclusion is that metrics showing very high values for certain classes or methods often indicate objects involved in major problems in the codebase. In this case study though, the measures seldom indicated objects for the ”right reason”, by which we mean the reason given in the literature. Because of this, the code metric values should not be used as a direct indication of what should be refactored but rather as a direction in which to look while doing a professional assessment. The results are not entirely in line with previous research, where common correlations between code metrics values and maintainability problems have been compiled. This is assumed to be due to the high degree of loose coupling in the studied code.

Bakgrund: Teknisk skuld är ett återkommande problem inom mjukvaruutveckling där det tycks vara omöjligt att undvika att samla på sig en teknisk skuld som över tid måste återbetalas innan den blir för komplex att handskas med. Detta har inneburit att man behöver hantera, åtgärda och återbetala den tekniska skulden med olika typer av tillvägagångssätt. Syfte: Syftet med denna studie var att intervjua tekniska ledare för att ta del av deras syn på vad teknisk skuld är och hur man hanterar den i det dagliga arbetet. För att kunna förstå termen teknisk skuld användes tidigare forskning och befintlig litteratur om ämnet. Metod: Undersökningsdesign i rapporten har följt en små-N-studie där nio respondenter har intervjuats från olika organisationer i Sverige. Intervjuerna genomfördes via digitala medel och samtliga intervjuer spelades in. Efter varje intervju transkriberades materialet med hjälp av Microsoft Word och renskrevs sedan av författarna i studien. Resultat: Resultatet visar att hanteringen av teknisk skuld skiljer sig beroende på vilken typ av bransch man är verksam inom. Det kan handla om hur man hanterar återbetalningen av teknisk skuld eller vilken typ av skuld som man samlar på sig. Slutsats: Fastän hanteringen och synen på teknisk skuld varierade mellan respondenterna så ansåg alla att det var väldigt viktigt att ta tag i och inget som man kunde ignorera. / Background: Technical debt is a recurring problem within software development where it seems impossible to avoid accumulating technical debt that over time must be repaid before the interest grows too large and complex to deal with. This has meant that you somehow need to handle, fix and repay the technical debt with many different approaches. Aim: The aim for this study was to interview tech leads about their view on what technical debt is and how it is managed in their daily work. To better understand the underlying concept of what a technical debt is and how it is managed we used prior research and existing literature about the subject. Method: The design method used in this report was of the type small-N-studies where nine respondents were interviewed from different organizations all located in Sweden. The interviews were transcribed using Microsoft Word and was then rewritten by the authors to be able to then analyze the material using a targeted content analysis with predetermined categories based on previous studies. Main result: The results show that the management of technical debt differs depending on the type of industry in which you operate. It can be about how to handle the repayment of technical debt or the type of debt that you accumulate. Conclusion: Although the management and view of technical debt varied between the respondents, everyone considered it very important to address and nothing that could be ignored. The technical debt was handled differently, but in the end the working methods were similar.