Technical debt is a metaphor that refers to the consequences of suboptimal software development. Developers will have to pay interest on this debt, in terms of costs of maintenance. The term helps developers communicate the importance of software quality. This thesis has studied technical debt in the context of Django web applications. In a survey conducted, the main causes of technical debt in Django applications were found to be architectural issues and lack of testing. This is in line with other studies of causes of technical debt. Tools and practices used in Django development were evaluated. From this evaluation several guidelines were formulated on how to best manage and limit technical debt. The results suggest that static code analyzers should be used to maintain code standards. Furthermore, the evaluation show that log aggregation tools like Sentry are helpful. Application monitoring should be used if there are performance issues, deprecation patterns can be used in refactorizations and the identification and removal of dead code is probably unnecessary. Finally, pre-commit tools help in preventing technical debt. / Teknisk skuld är en metafor som beskriver konsekvenserna utav suboptimal mjukvaruutveckling. Utvecklare måste betala ränta på denna skuld, i form utav kostnader för underhåll. Termen hjälper utvecklare att kommunicera vikten utav programvarukvalitet. Denna rapport har studerat teknisk skuld i kontexten utav Django webbapplikationer. En enkätundersökning gjordes och de främsta orsakerna till teknisk skuld i Django applikationer visade sig vara arkitektoniska problem och brist utav testning. Detta ligger i linje med andra studier utav orsakerna av teknisk skuld. Verktyg och metoder som används i Django utveckling utvärderades. Från denna utvärdering flera riktlinjer formulerades om hur man bäst hanterar och begränsar teknisk skuld. Resultaten visar på att statisk programanalys bör användas för att upprätthålla kod standarder. Dessutom visar utvärderingen att log aggregerings verktyg som Sentry är användbara. Applikations övervakning bör användas om det finns prestandaproblem, deprecation patterns kan användas i refaktoriseringar och identifiering av död kod är förmodligen onödigt. Slutligen visar sig pre-commit verktyg vara hjälpsamma i att förebygga teknisk skuld.

The technical debt field covers an critical problem of software engineering, and this is one of the reasons why this field has received significant attention in recent years. The technical debt metaphor helps developers to think about, and to monitor software quality. The metaphor refers to flaws in software (usually caused by shortcuts to save time) that may affect future maintenance and evolution. It was created by Cunningham to improve the quality of software delivery. Many times the technical debt items are unknown, unmonitored and therefore not managed, thus resulting in high maintenance costs throughout the software life-cycle. We conducted an empirical study in an academic environment, during two offerings of a laboratory course on Extreme Programming (XP Lab) at University of São Paulo and in two Brazilian Software Companies (Company A and B). We analyzed thirteen teams, nine in the Academy and four in the Companies environment. The teams had a comprehensive lecture about technical debt and several ways to identify and manage technical debt were presented. We monitored the teams, performed interviews, did close observations and collected feedback. The obtained results show that the awareness of technical debt influences team behavior. Team members report thinking and discussing more on software quality after becoming aware of technical debt in their projects. We identified some impacts on the teams and the projects after having considered technical debt. A conceptual model for technical debt management was created including ways of how identifying, monitoring, categorizing, measuring, prioritizing, and paying off the technical debt. A few approaches and techniques for the technical debt management, identification, monitoring, measure, and payment are also suggested. / A metáfora de dívida técnica engloba um importante problema da engenharia de software e essa é uma das razões pelas quais este campo tem recebido uma grande atenção nos últimos anos. Essa metáfora auxilia os desenvolvedores de software a refletirem sobre e a monitorarem a qualidade de software. A metáfora se refere a falhas no software (geralmente causadas por atalhos para economizar tempo) que podem afetar a futura manutenção e evolução do mesmo. A metáfora foi criada por Cunningham com o objetivo de melhorar a qualidade das entregas de software. Muitas vezes as dívidas técnicas não são conhecidas, monitoradas e nem geridas, resultando em um alto custo de manutenção ao longo do ciclo de vida do software. Logo, conduziu-se um estudo empírico na academia, durante duas ofertas da disciplina de Programação Extrema (XP Lab) na Universidade de São Paulo e em duas empresas Brasileiras de desenvolvimento de software (Empresa A e B). Foram analisados treze times, sendo nove na academia e quatro nas empresas. Os times tiveram uma apresentação sobre dívida técnica e foram apresentadas algumas sugestões de abordagens para gerir dívida técnica. Monitorou-se os times, foram realizadas entrevistas, observações fechadas e informações foram coletadas. Os resultados mostraram que considerar dívida técnica influenciou o comportamento dos times. Eles reportaram que após considerar dívida técnica passaram a refletir e discutir mais a qualidade do software. Identificou-se alguns impactos nos times e nos projetos depois de considerarem dívida técnica. Um modelo conceitual para gestão de dívida técnica foi criado, incluindo formas, técnicas e abordagens de como identificar, monitorar, categorizar, medir, priorizar e pagar os itens de dívida técnica.

The technical debt field covers an critical problem of software engineering, and this is one of the reasons why this field has received significant attention in recent years. The technical debt metaphor helps developers to think about, and to monitor software quality. The metaphor refers to flaws in software (usually caused by shortcuts to save time) that may affect future maintenance and evolution. It was created by Cunningham to improve the quality of software delivery. Many times the technical debt items are unknown, unmonitored and therefore not managed, thus resulting in high maintenance costs throughout the software life-cycle. We conducted an empirical study in an academic environment, during two offerings of a laboratory course on Extreme Programming (XP Lab) at University of São Paulo and in two Brazilian Software Companies (Company A and B). We analyzed thirteen teams, nine in the Academy and four in the Companies environment. The teams had a comprehensive lecture about technical debt and several ways to identify and manage technical debt were presented. We monitored the teams, performed interviews, did close observations and collected feedback. The obtained results show that the awareness of technical debt influences team behavior. Team members report thinking and discussing more on software quality after becoming aware of technical debt in their projects. We identified some impacts on the teams and the projects after having considered technical debt. A conceptual model for technical debt management was created including ways of how identifying, monitoring, categorizing, measuring, prioritizing, and paying off the technical debt. A few approaches and techniques for the technical debt management, identification, monitoring, measure, and payment are also suggested. / A metáfora de dívida técnica engloba um importante problema da engenharia de software e essa é uma das razões pelas quais este campo tem recebido uma grande atenção nos últimos anos. Essa metáfora auxilia os desenvolvedores de software a refletirem sobre e a monitorarem a qualidade de software. A metáfora se refere a falhas no software (geralmente causadas por atalhos para economizar tempo) que podem afetar a futura manutenção e evolução do mesmo. A metáfora foi criada por Cunningham com o objetivo de melhorar a qualidade das entregas de software. Muitas vezes as dívidas técnicas não são conhecidas, monitoradas e nem geridas, resultando em um alto custo de manutenção ao longo do ciclo de vida do software. Logo, conduziu-se um estudo empírico na academia, durante duas ofertas da disciplina de Programação Extrema (XP Lab) na Universidade de São Paulo e em duas empresas Brasileiras de desenvolvimento de software (Empresa A e B). Foram analisados treze times, sendo nove na academia e quatro nas empresas. Os times tiveram uma apresentação sobre dívida técnica e foram apresentadas algumas sugestões de abordagens para gerir dívida técnica. Monitorou-se os times, foram realizadas entrevistas, observações fechadas e informações foram coletadas. Os resultados mostraram que considerar dívida técnica influenciou o comportamento dos times. Eles reportaram que após considerar dívida técnica passaram a refletir e discutir mais a qualidade do software. Identificou-se alguns impactos nos times e nos projetos depois de considerarem dívida técnica. Um modelo conceitual para gestão de dívida técnica foi criado, incluindo formas, técnicas e abordagens de como identificar, monitorar, categorizar, medir, priorizar e pagar os itens de dívida técnica.

The importance of software code quality is increasing rapidly. With more code being written every day, its maintenance and support are becoming harder and more expensive. New automatic code review tools are developed to reach quality goals. One of these tools is SonarQube. However, people keep their leading role in the development process. Sometimes they sacrifice quality in order to speed up the development. This is called Technical Debt. In some particular cases, this process can be admitted by the developer. This is called Self-Admitted Technical Debt (SATD). Code quality can also be measured by such static code analysis tools as SonarQube. On this occasion, different issues can be detected. The purpose of this study is to find a connection between code quality issues, found by SonarQube and those marked as SATD. The research questions include: 1) Is there a connection between the size of the project and the SATD percentage? 2) Which types of issues are the most widespread in the code, marked by SATD? 3) Did the introduction of SATD influence the bug fixing time? As a result of research, a certain percentage of SATD was found. It is between 0%–20.83%. No connection between the size of the project and the percentage of SATD was found. There are certain issues that seem to relate to the SATD, such as “Duplicated code”, “Unused method parameters should be removed”, “Cognitive Complexity of methods should not be too high”, etc. The introduction of SATD has a minor positive effect on bug fixing time. We hope that our findings can help to improve the code quality evaluation approaches and development policies

Technical Debt (TD) is a concept referring to technical deficiencies and sub-optimal decisions made in software development that may save time in the short term but lead to long-term obstacles. The concept also implies increased future costs, often growing with interest, caused by slower development rates and the need for refactorings. The high-paced environment of tech start-ups often leads to companies taking shortcuts in their development process, prioritizing iteration speed and time-to-market over longterm scalability. Oftentimes resulting in the accumulation of TD through sub-optimal technology choices, modularity, or architecture. Start-ups also play an important role in the innovation of many industries, hence, their contribution to differing markets and new products is valuable. Poorly managed TD in start-ups may lead to large obstacles when initiating a scale-up phase, leading to a possible development in industries slowing down, and it is therefore important to create the best possible conditions for start-ups to succeed in managing their TD, which is where this study aims to provide aid. A multiple-case study was performed with several tech start-ups in the Stockholm area on how TD has emerged and has been managed through its journey. The findings show that start-up companies are often inclined to deliberately accumulate TD in the early stages, in order to facilitate swift market establishment and proof of concept for their product. Further, the negative consequences of early accumulated TD were found to be limited. However, TD should not be left to grow for too long even in a start-up phase, since the findings show that this often results in large costs. Instead, start-ups should plan for there factoring of early accumulated TD by expecting a technological pivot. Furthermore, in the continuous management of TD, the results show that team composition, including personality traits and in-house competence, often impacts the success of managing TD more than meticulous planning, motivating the management in the start-ups to more thoroughly consider how they build their teams, and what competencies are present in the company, or needed. / Teknisk Skuld är ett begrepp som syftar på suboptimala beslut som fattas inom mjukvaruutveckling som kan spara tid på kort sikt, men som innebär framtida kostnader, ofta med ränta, genom refaktorering eller långsammare utvecklingstid. Den snabba miljön hos tech start-ups leder ofta till att företag tar genvägar i sin utveckling, vad gäller till exempel teknikval, modularitet eller arkitektur. Start-ups spelar också en viktig roll i innovationen i många branscher, och är därför värdefulla i olika marknader och nya produkter. Dåligt skött teknisk skuld i nystartade företag kan leda till stora hinder närman initierar en uppskalningsfas, vilket leder till att eventuell utveckling i branscher bromsar in, och det är därför viktigt att skapa de bästa möjliga förutsättningarna för start-ups att lyckas hantera sina tekniska skuld, vilket denna studie syftar till att bidra till. I den här artikeln genomfördes en flerfallsstudie med flera nystartade teknikföretag i Stockholmsområdet om hur teknisk skuld har vuxit fram och hanterats genom sin resa. Resultaten visar att teknisk skuld inte anses vara dåligt i mycket tidiga skeden, där ackumuleringen av teknisk skuld ofta skapar marknadsetablering och samlar bevis för vad produkten bör vara för, och tidigt ackumulerad teknisk skuld är oftast lättare att hantera än i senare skeden. Teknisk skuld bör dock inte lämnas att växa för länge även i en uppstartsfas, eftersom resultaten visar att detta ofta leder till alldeles för stora kostnader. Istället bör nystartade företag planera för omstrukturering av tidigt ackumulerad teknisk skuld genom att förvänta sig en teknisk pivot. Vidare, i den kontinuerliga hanteringen av teknisk skuld, visar resultaten att team-sammansättning, inklusive personlighetsdrag och intern kompetens, ofta påverkar framgången med att hantera teknisk skuld mer än noggrann planering, vilket motiverar ledningen i nystartade företag att mer noggrant överväga hur de bygger sina team och vilka kompetenser som finns i företaget, eller vilka som behövs.

Context: In an era where every industry is impacted by software, it is vital to keep software costs under control for organizations to be competitive. A key factor contributing to software costs is software maintenance where a significant proportion is utilized to deal with different types of technical debt. Technical debt is a metaphor used to describe the cost of taking shortcuts or sub-optimal design and implementation that compromises the software quality. Similar to financial debt, technical debt needs to be paid off in the future. Objective: To be in control of technical debt related costs, organizations need to identify technical debt types and quantify them to introduce solutions and prioritize repayment strategies. However, the invisible nature of technical debt makes its identification challenging in practice. Our aim is to find pragmatic ways to identify technical debt in practice, that can be supported by evidence. Once technical debt types that are significant have been identified, we aim to propose suggestions to mitigate them. Method: We used design science as a methodological framework to iteratively improve the technical debt identification methods. We utilized bug reports, which are artifacts produced by software engineers during the development and operation of the software system  as the data source for technical debt identification. Software defects reported through bug reports are considered as one of the key external quality attributes of a software system  which supports us in our evidence based approach. Throughout the design science iterations, we used the following research methods: case study and sample study. Results: We produced three design artifacts that support technical debt identification. The first artifact is a systematic process to identify architectural technical debt from bug reports. The second is an automated bug analysis and a visualization tool to support our research as well as to support practitioners to identify components with hot spots in relation to the number of defects. The third is a method for identifying documentation debt from bug reports. Conclusion: Based on the findings from this thesis, we demonstrated that bug reports can be utilized as a data source to identify technical debt in practice by identifying two types of technical debt; architectural technical debt and documentation debt. Compared to the identification of documentation debt, architectural technical debt identification still remains challenging due to the abstract nature of the architecture and its boundaries. Therefore, our future work will focus on evaluating the impact of reducing the sources of documentation debt on the frequency of bug reports and overall project cost.

Context: Technical debt, the process of introducing sub-optimal so-lutions for short-term profit at the expense of long-term effectiveness,is a new and upcoming research field and has been shown in multiplestudies to affect different human aspects, such as moral and affectivestates. Objectives: The aim of this study is to investigate how technicaldebt impacts stress in both developers and project managers. Methods: The study consisted of two main parts, one literature re-view and one case study. The case study consisted of semi-structuredinterviews with 11 participants which were then thematically analyzed. Results: The results show that technical debt which directly impactsthe efficiency and performance of the developers has a negative impacton stress, which the study found to primarily consist of test debt andcode debt. It also suggests that project managers are generally lessimpacted by technical debt and are more liberal towards introducingit to the system. Conclusions: The study found that developers are more directlyimpacted by technical debt and are, hence, more critical towards itsintroduction. Project managers, on the other hand, are impacted byit to a lesser degree and therefore, in combination with the pressuresand requirements by the customer, prefers a “good enough” solutionover a perfect solution.

Context. There is a need for developers to write clean code and code that adheres to a high-quality standard. We need developers not to introduce technical debt and code smells to the code. From a business perspective, developers that introduce technical debt to the code will make the code more difficult to maintain, meaning that the cost for the project will increase. Objectives. The main objective of this study is to gain an understanding about the perception the developers have about clean code and how they use it in practice. There is not much information about how clean code is perceived by developers and applied in practice, and this thesis will extend the information about those two areas. It is an effort to understand developers' perception of clean code in practice and what they think about it. Realization (Method). To understand the state-of-the-art in the area of clean code, we first performed  literature review using snowballing. To delve into developers' perception about clean code and how it is used in practice. We have developed and sent out a questionnaire survey to developers within companies and shared the survey via social networks. We ask if developers believe that clean code eases the process of reading, modifying, reusing, or maintaining code. We also investigate whether developers write clean code initially or refactor it to become clean code, or do none of these. Finally, we ask developers in practice what clean code principles they agree or disagree with. Asking this will help identify which clean code principles developers think are helpful and which are not. Results. The results from the investigation are that the developers strongly believe in clean code and that it affects reading, modifying, reusing, and maintaining code, positively. Also, developers do not write clean code initially but rather refactor unclean code to become clean code. Only a small portion of developers write clean code initially, and some do what suits the situation, while some do neither of these. The last result is that developers agree with most of the clean code principles listed in the questionnaire survey and that there are also some principles that they discard, but these fewer. Conclusions. From the first research question, we know that developers strongly believe that clean code makes the code more readable, understandable, modifiable, or reusable. Also, developers check that the code is readable using code reviews, peer reviews, or pull requests. Regarding the second research question, we know that developers mostly refactor unclean code rather than write clean code initially. The challenges are that to write clean code initially, a developer must have a solid understanding of the problem and obstacles in advance, and a developer will not always know what the code should look like in advance. The last research question showed that most developers agree with most of the clean code principles and that only a small portion of developers disagree with some of them. Static code analysis and code quality gates can ensure that developers follow these clean code practices and principles.

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.

Arkitektoniska beslut har ofta långvariga effekter på system. När beslut leder till ökad komplexitet, underhållbarhet och hämmad utvecklingshastighet, uppstår arkitektonisk teknisk skuld. Arkitektonisk teknisk skuld kan betraktas som mer relevant än någonsin i en tid där vi inte bara är mer beroende av våra informationssystem än någonsin, de är också mer komplexa än någonsin. Systemen fortsätter öka i skala och ny teknologi, såsom AI, tillkommer och blir snabbt en del av gemene mans vardagliga arbete. Arkitektoniska beslut fattas inte bara vid ett tidigt skede med dagens agila utvecklingsmetoder, utan kontinuerligt under iterationer. Detta kan leda till genvägar och därmed suboptimala arkitektoniska beslut, vilket i sin tur kan ge upphov till arkitektonisk teknisk skuld över tid. Denna masteruppsats om arkitektonisk teknisk skuld i en molnbaserad miljö är en fallstudie som undersöker organisationer verksamma inom CRM-systemet Salesforce, mer specifikt systemutveckling inom ramen för detta. Studien undersöker organisationernas uppfattning och hantering av fenomenet, men även hur deras attityder och risktagande ser ut vid arkitektoniska beslut. Studien presenterar tidigare forskning om teknisk skuld, den finansiella metaforen av Ward Cunningham, arkitektonisk teknisk skuld, en kategori av teknisk skuld, och använder två teoretiska ramverk: en deskriptiv modell för att tolka arkitektonisk teknisk skuld och en analytisk modell som kategoriserar teknisk skuld enligt Fowlers kvadranter, med en arkitektonisk tappning. Resultatet består av en empirisk insamling där dokumentation från Salesforce presenteras och åtta respondenter med olika roller har intervjuats. Studien visar att det råder skillnader i hur organisationer hanterar arkitektonisk teknisk skuld beroende på uppdragsgivarens roll och förståelse, att det finns utmaningar med att få hantering av arkitektonisk teknisk skuld prioriterad, samt att det råder både vårdslösa och eftertänksamma attityder. / Architectural decisions often have long lasting effects on information systems, when these decisions lead to increased complexity, maintainability, and inhibited development speed, architectural technical debt arises. Architectural technical debt can be considered more relevant than ever in an age where we are not only more dependent on our information systems than ever, they are also more complex than ever. The systems continue to increase in scale and new technology, such as AI, is added and quickly becomes part of the everyday work of the average person. Architectural decisions are made not only once at an early stage with today’s agile development methods, but continuously during iterations. This can lead to shortcuts and thus suboptimal architectural decisions, which in turn can create architectural technical debt over time. This master’s thesis on architectural technical debt in a cloud-based environment is a case study that examines organizations operating within the CRM system Salesforce, more specifically system development within this framework. The study examines the organizations' perception and management of the phenomenon, but also what their attitudes and risk-taking look like in architectural decisions. The study presents previous research on technical debt, the financial metaphor of Ward Cunningham, and architectural technical debt, a category of technical debt, and uses two theoretical frameworks: a descriptive model to interpret architectural technical debt and an analytical model that categorize technical debt according to Fowler’s quadrants, with an architectural angle. The result consists of an empirical collection where documentation from Salesforce is presented and eight respondents with different roles have been interviewed. The study shows that there are differences in how organizations handle architectural technical debt depending on the client's role and understanding, that there are challenges with getting handling of architectural technical debt prioritized, and that there are both reckless and prudent attitudes.