Technical debt management in a large-scale distributed project : An Ericsson case study

• Main Authors: Gong, Zhixiong, Lyu, Feng
• Format: Others
• Language: English
• Published: Blekinge Tekniska Högskola, Institutionen för programvaruteknik 2017
• Subjects: technical debt management; large-scale distributed project; factors.; Software Engineering; Programvaruteknik
• Online Access: http://urn.kb.se/resolve?urn=urn:nbn:se:bth-14803

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.