Context. Technical debt (TD) is a metaphor reflecting technical compromises that sacrifice long-term health of a software product to achieve short term benefit. TD is a strategy for the development team to obtain business value. TD can do both harm and good to a software based on the situation of TD accumulation. Therefore, it is important to manage TD in order to avoid the accumulated TD across the breaking point. In large-scale distributed projects, development teams located in different sites, technical debt management (TDM) becomes more complex and difficult compared with traditional collocated projects. In recent years, TD metaphor has attracted the attention from academics, but there are few studies in real settings and none in large-scale globally distributed projects. Objectives. In this study, we aim to explore the factors that have significant impact on TD and how practitioner manage TD in large-scale distributed projects. Methods. We conducted an exploratory case study to achieve the objectives. The data was collected through archival records and a semi-structured interview. For the archival data, hierarchical multiple regression was used to analyze the relationship between identified factors and TD. For interview data, we used qualitative content analysis method to get a deep understanding of TDM in this studied case. Results. Based on the results of archival data analysis, we identified three factors that show significant positive correlation with TD. These three factors were task complexity, global distance, and maturity, which were evaluated by the architect during the semi-structured interview. The architect also believed that these factors have strong relationships with TD. TDM in this case includes seven management activities: TD prevention, identification, measurement, documentation, communication, prioritization, and repayment. The tool used for TDM is an internally implemented tool called wiki page. We also summarize the roles involved and approaches used with respect to each TDM activity. Two identified TDM challenges in this case were TD measurement and prioritization. Conclusions. We conclude that 1) TDM in this case is not complete. Due to the lack of TD monitoring, the measurement of TD is static and lacks an efficient way to track the change of cost and benefit of unresolved TD over time. Therefore, it is difficult to find a proper time point to repay a TD. 2) The wiki page is not enough to support TDM, and some specific tools should be combined with wiki page to manage TD comprehensively. 3) TD measurement and prioritization should get more attention both from practitioners and academics to find a suitable way to solve such challenges in TDM. 4) Factors that make significant contribution to TD should be carefully considered, which increase the accuracy of TD prediction and improve the efficiency of TDM.

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.

Deficiencies in software design or architecture can severely impede and slow down the software development and maintenance progress. Bad smells and anti-patterns can be an indicator for poor software design and suggest for refactoring the affected source code fragment. In recent years, multiple techniques and tools have been proposed to assist software engineers in identifying smells and guiding them through corresponding refactoring steps. However, these detection tools only cover a modest amount of smells so far and also tend to produce false positives which represent conscious constructs with symptoms similar or identical to actual bad smells (e.g., design patterns). These and other issues in the detection process demand for a code or design review in order to identify (missed) design smells and/or re-assess detected smell candidates. UML diagrams are the quasi-standard for documenting software design and are often available in software projects. In this position paper, we investigate whether (and to what extent) UML diagrams can be used for identifying and assessing design smells. Based on a description of difficulties in the smell detection process, we discuss the importance of design reviews. We then investigate to what extent design documentation in terms of UML2 diagrams allows for representing and identifying software design smells. In particular, 14 kinds of design smells and their representability in UML class and sequence diagrams are analyzed. In addition, we discuss further challenges for UML-based identification and assessment of bad smells.

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.

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.