1 Introduction↩︎

Software-intensive organizations continuously face the challenge of evolving complex systems under limited time and resource constraints [1]. In such settings, maintenance and evolution decisions are rarely driven by the goal of improving all problematic code equally; instead, teams must decide where intervention is most worthwhile and which parts of a system most urgently deserve refactoring or restructuring [2], [3]. Existing software analytics provide useful signals for this purpose, including code health indicators, hotspots, change coupling, and ownership-related metrics [3]–[6]. However, in practice, teams need a more direct way to reason about the experienced burden of change: not only whether code appears problematic in isolation, but whether it slows down development, complicates maintenance, increases coordination effort, or raises the cost of future evolution [5], [7].

This practical concern motivates the notion of technical debt friction. In this paper, we use the term technical debt friction to denote the practical resistance that problematic parts of a system impose on ongoing maintenance and evolution [8]. To the best of our knowledge, technical debt friction is not a standard term in the technical debt literature; rather, it appears to have emerged as a practice-oriented operationalization of how technical debt affects development productivity and change effort [8], [9]. Rather than focusing narrowly on structural quality defects, technical debt friction aims to capture the resistance that parts of a system create during ongoing change and maintenance. Such resistance may arise from poor code quality, but also from broader factors such as recurring change concentration, unstable dependencies, refactoring difficulty, fragmented ownership, or knowledge bottlenecks [1], [2], [4], [5], [7], [10]. For industrial teams, this perspective is attractive because it speaks directly to day-to-day engineering concerns: which parts of the system are most difficult to work with, which areas consume disproportionate effort, and where improvement work is most likely to pay off.

Despite this promise, the usefulness of technical debt friction cannot be assumed. A concept intended for industrial decision making must be understandable to practitioners, aligned with their experience, and sufficiently actionable to support prioritization. Otherwise, it risks becoming yet another abstract software quality label with limited practical value. This creates an important problem for both researchers and tool builders: while many software analytics concepts are technically plausible, far fewer have been examined in terms of how practitioners actually interpret them, whether they trust them, and how they use them when reasoning about real maintenance pain points. In particular, it remains unclear whether technical debt friction provides added value beyond more established views such as code health, hotspots, or coupling analyses, or whether practitioners instead see it as a relabeling of existing quality concerns.

To address this problem, we conducted a multi-case industrial study to investigate the practical usefulness of technical debt friction in software maintenance and evolution. Our study examines how practitioners interpret the concept when applied to their own systems, whether friction-related signals align with their perceptions of maintenance pain points and refactoring needs, and what benefits and limitations emerge when the concept is discussed in real industrial contexts. The study addresses the following research questions (RQs):

• RQ1: How do practitioners interpret technical debt friction when applied to real industrial software systems?

• RQ2: To what extent does technical debt friction align with practitioners’ perceptions of maintenance pain points and refactoring needs?

• RQ3: Can project-level friction distributions provide broader maintenance and evolution insights beyond individual refactoring candidates?

The study covers multiple industrial cases and involves practitioners with direct knowledge of the analyzed systems. Using structured walkthrough sessions centered on CodeScene [11] analysis artifacts, including code health, hotspots, coupling, refactoring targets, and socio-technical views, we collected evidence on the interpretability, credibility, and actionability of the friction concept across cases.

Our findings show that practitioners generally regarded technical debt friction as a meaningful and useful concept for reasoning about maintenance burden, but not as a standalone signal. Across the studied products, friction was most useful when discussed together with complementary views such as code health, hotspots, coupling, and socio-technical information, and when interpreted in relation to product context, architectural centrality, and ongoing development activity. At file level, friction often aligned with areas that practitioners already considered problematic and, in several cases, with files that later received maintenance or refactoring attention. At the same time, the study also showed that high friction does not uniformly imply high practical importance: isolated files, test code, and temporary activity spikes required more careful interpretation. Beyond individual candidates, our exploratory project-level analysis further suggests that friction distributions may provide broader insights into how maintenance effort is distributed across a system. These findings indicate that technical debt friction is promising as a maintenance-oriented decision-support concept, but that its practical value depends on contextual interpretation and supporting evidence.

The paper is structured as follows. Section 2 presents the background. In Sections 3 and 4, we present our research design and the results, respectively. In Section 5, we discuss cross-case findings. Section 6 summarizes the threats to the validity of our study. Section 7 discusses the related work. We conclude the paper in Section 8.

2 Background and Conceptual Framing↩︎

2.1 Technical Debt and Maintenance Prioritization↩︎

Software maintenance and evolution require continuous prioritization [1]. Since teams cannot address all quality issues at once, they must focus limited effort where it yields the greatest practical benefit [2]. Although technical debt captures how suboptimal decisions increase future maintenance costs, it remains a broad concept. In practice, teams need support not only to identify technical weaknesses, but also to determine which ones most strongly hinder ongoing development [2]. Software analytics provide useful signals, including code quality indicators, hotspots, and ownership-related views [3]–[5]. These can reveal technically problematic, change-prone, or organizationally risky parts of a system [3], [7]. However, such signals often remain fragmented, leaving teams without an integrated view of which parts impose the greatest practical burden on maintenance and evolution.

2.2 CodeScene CodeHealth and Hotspots↩︎

CodeHealth™ (CH) is a quality metric in the CodeScene SE intelligence platform [11] intended to capture how cognitively difficult source code is for developers to understand. It combines the number and severity of detected code smells into a file-level score from 1 to 10, where lower scores indicate higher cognitive load and maintenance effort. CodeScene also reports LoC-weighted CH averages at the project level, for architectural components, and for user-selected file sets. Prior work has validated CH through its association with file-level defect density and development time [12], [13], as well as in a comparative study on a public benchmark [14]. CodeScene uses hotspots to identify the code with the highest development activity. In active projects, file revisions typically follow a highly skewed distribution, where a small subset of files accounts for a large share of changes. CodeScene identifies this subset through knee-point analysis of the change-frequency distribution, separating frequently modified files from the long tail of rarely changed ones. The average CH of the flagged hotspot files is referred to as the Hotspot CH (HS_CH).

2.3 Technical Debt Friction↩︎

Technical debt friction denotes the practical resistance parts of a system impose on ongoing maintenance and change [8]. This resistance may stem from structural weaknesses, frequent changes, unstable dependencies, refactoring difficulty, or socio-technical factors such as fragmented ownership and knowledge bottlenecks [2], [4], [5], [7], [15]. The concept shifts attention from isolated quality deficiencies to their concrete impact on day-to-day software work. Since maintenance difficulties typically arise from the interplay of technical and organizational conditions rather than a single cause [5], [7], technical debt friction aims to capture this broader burden and support more effective maintenance prioritization [8].

We calculate friction at two levels. At the project level, friction is used for characterizing and comparing projects, resulting in a score on a bounded 0–99 scale as follows:

\[\text{Fric}_{\text{proj}} = (10 - \text{HS\_CH}) + \left(100 - 10 \cdot \frac{\sum_{f \in F} CH_f \cdot Rev_f}{\sum_{f \in F} Rev_f} \right)\]

where \(f \in F\) denotes the individual files in the project, \(CH_f\) is the CodeHealth of file \(f\), and \(Rev_f\) is the number of revisions to file \(f\). We refer to the first term as the start friction and the second term as the dynamic friction. Note that the activity-weighted term includes only files with at least one revision during the analysis period (default value: 1 year). If no file has been revised, project-level friction is undefined. We discuss project-level friction scores in Section 4.3.

At the file-level, friction is calculated for localization and visualization in the interactive user interface. This score also combines relative revision activity and CH, while reserving part of the visual scale to emphasize leading hotspots. In Section 4.2 we discuss file-level friction scores.

2.4 Relation to Adjacent Concepts↩︎

Technical debt friction is related to, but distinct from, several established concepts. It goes beyond code health by emphasizing the practical burden of evolving code [8]. It also differs from hotspots, which in CodeScene identify files with high development activity regardless of code quality. Earlier platform versions combined hotspots with low-code health to flag a small, actionable subset of files, whereas technical debt friction provides a more fine-grained signal of how development activity interacts with maintainability concerns across the codebase. Likewise, change coupling may reveal one source of maintenance difficulty, but does not itself capture the broader resistance experienced in practice [4]. Nor is high friction equivalent to a refactoring decision, which also depends on strategic importance, business constraints, and implementation cost [2]. Finally, technical debt friction also has a socio-technical dimension: maintenance burden depends not only on code structure, but also on how knowledge, ownership, and coordination are distributed across the team [5], [7]. We therefore view technical debt friction as an integrative concept for reasoning about maintenance burden through the combined lens of change activity and maintainability.

2.5 Study Focus↩︎

Our goal is not to position technical debt friction as a replacement for concepts such as technical debt, code health, or hotspots. Instead, we treat it as a practice-oriented concept whose value depends on whether practitioners find it understandable, credible, and useful in real development contexts. Accordingly, we examine whether practitioners interpret friction meaningfully, whether friction-related analyses align with perceived development pain points, and whether the concept supports actionable maintenance prioritization. In this sense, debt friction serves as a decision-support lens for identifying where a system most strongly resists change and where improvement efforts may yield the greatest practical benefit.

3 Research Design↩︎

We conducted a multi-case exploratory case study [16] with practitioner-based concept validation. While RQ1 and RQ2 are grounded in the practitioner interviews and walkthrough sessions, RQ3 complements this design with an exploratory project-level analysis of friction distributions.

3.1 Analyzed Projects↩︎

This study analyzed three industrial software products with CodeScene, with Products A and C each represented by two versions (Table 1). The cases span modern IoT and data-integration platforms as well as a large legacy monolith, and vary substantially in size (117K–2.8M LOC) and architectural complexity (19–76 components). Product C is the largest, a 2.8M-LOC monolithic system, whereas Products A and B are more modern codebases. Product A is a UI-intensive application connected to a backend IoT system, and Product B is a modern .NET system with some JavaScript and Python. Despite their smaller size, Products A and B contain more architectural components than Product C, indicating greater modularity. The products include minor Python integrations.

3.2 Data Collection - Tools↩︎

We used CodeScene [11] as the main analysis tool because it provides an integrated set of code, evolutionary, and socio-technical views relevant to our study, including Code Health, Hotspots, and Technical Debt Friction. A key reason for this choice is that CodeScene directly provides Technical Debt Friction as an analysis view. This was important because our goal was not to construct a new friction metric, but to investigate whether this tool-supported notion is meaningful and useful in industrial practice. We therefore used CodeScene as an analysis and discussion aid to ground practitioner discussions about maintenance pain points, refactoring needs, and the practical burden of change.

Figure 1 shows an example Technical Debt Friction view in CodeScene. It highlights parts of the codebase where current code health and recent development activity combine to create likely maintenance burden. Circle size reflects the LOC of individual files, while larger gray directory circles indicate directories with more files. Color encodes Technical Debt Friction, combining present code health with commit activity over the last 12 months, with warmer colors indicating higher friction. The view thus helps identify locations where technical debt is most likely to affect day-to-day development work and improvement efforts may have the greatest practical payoff.

3.3 Data Collection - Survey with Practitioners↩︎

To analyze each software product, we deployed the dockerized CodeScene tool on company-provided Linux virtual machines (VMs). Product owners cloned their codebases onto these VMs, and researchers were given restricted access to run the tool. We documented the results and conducted online seminars with developers, architects, and managers; CodeScene worked successfully across all products (Table 1). The interviews were conducted as part of a case study on how practitioners perceive and use socio-technical analysis results in daily work. Using a semi-structured protocol, the researcher shared their screen, navigated the CodeScene reports for the participant’s project, and prompted discussion.

Across all interviews, we followed the same sequence: (i) introduction and overview of CodeScene results, (ii) code health, (iii) hotspots, (iv) friction and change coupling, and (v) evaluation of friction and overall usefulness.

3.3.1 Introduction and Overview of CodeScene Results↩︎

Each interview began with a short explanation of the study purpose. The interviewer then opened the project’s CodeScene dashboard and briefly introduced the main views, including overall status, code health, hotspots, and friction.

3.3.2 Exploration of Code Health↩︎

The interviewer focused on the Code Health view and selected a file with low code health in the interface. CodeScene’s warnings and violations (e.g., many conditionals, complex methods, cyclomatic complexity and its evolution) were discussed, and the corresponding source code was shown when needed. Participants were asked whether these indicators matched their assessment of the code.

3.3.3 Hotspot Analysis↩︎

The interviewer then used the Hotspots view, showing commits over the last 12 months, and highlighted files with high change frequency. Participants reflected on whether these hotspots matched their expectations and experience of frequently modified parts of the system.

3.3.4 Friction↩︎

The interviewer introduced friction as high development activity in low-quality code. Using CodeScene’s friction view, one highly flagged file was selected (multiple flagged files were selected for each product), and participants were asked whether they recognized it as a source of friction, whether it had caused problems in practice, and whether they had refactored or would consider refactoring it.

3.3.5 Friction and Change Coupling↩︎

The interviewer also showed dependencies and change-coupling information for the same file, asking how well these patterns reflected the actual architecture and coordination needs and whether such information would be useful for planning refactorings.

3.3.6 Evaluation of Friction and Overall Usefulness↩︎

In the final part, participants assessed the usefulness of the friction view and the CodeScene reports overall. They commented on which views and metrics they found most or least useful, how they might use such analyses to prioritize refactoring and maintenance, and whether these visualizations could help communicate technical debt and quality concerns to others.

3.3.7 Data Collection and Analysis↩︎

Interviews were conducted remotely via video conferencing, with audio and screen sharing recorded subject to consent. The interviewer took notes in each session, and recordings were transcribed verbatim. We applied thematic coding [17], focusing on (i) how practitioners interpret automated quality indicators, (ii) how they relate hotspots and friction to their lived experience of the codebase, and (iii) under what conditions they consider such metrics actionable. The shared protocol and tool sequence ensured comparability across interviews while allowing open-ended, in-depth discussion. Table 2 presents the study participants.

4 Results↩︎

4.1 RQ1: Practitioner Interpretation of Technical Debt Friction↩︎

To address RQ1, we analyzed how practitioners discussed and assessed Technical Debt Friction across the three products, focusing on whether they found it meaningful in practice, which files and maintenance situations they associated with it, and which contextual factors shaped their interpretation.

Across the products, participants generally found Technical Debt Friction useful when the flagged files corresponded to maintenance-relevant parts of the codebase. At the same time, they did not treat friction as a standalone signal, but interpreted it through knowledge of the codebase, file role, architecture, and current development context. We identified four findings.

4.1.0.1 Friction often aligned with existing practitioner knowledge

High-friction files frequently overlapped with files that participants already considered problematic. In Product C, one flagged file was recognized as a likely source of friction because of deep nesting, brain class characteristics, and low cohesion. In Product A, highly flagged files were similarly associated with bumpiness and nested complexity, and one was later refactored, reducing friction and improving code health. This overlap suggests that friction often resonated with lived experience rather than surfacing only implausible candidates.

4.1.0.2 Friction could also surface less expected candidates, but these required contextual interpretation

The sessions also highlighted files that practitioners had not initially expected, though these still required validation. In Product C, one flagged file showed low cohesion, bumpiness, and nested complexity, and participants confirmed that it was functionally overloaded, making it a plausible refactoring candidate despite not having been highlighted beforehand. At the same time, not all unexpected files were equally important. In Product B, where the standout files showed lower overall friction than in the other products, one flagged file was still recognized as complex and frequently changed, but the participants considered its issues less severe in context due to its role. These cases show that participants did not interpret friction mechanically, but used it as a prompt for further inspection and validation.

4.1.0.3 Practitioners did not treat friction as an automatic refactoring signal

They interpreted friction as an indicator of burden, but not necessarily as a direct trigger for action. In Product C, one high-friction file was treated as lower priority because it was isolated and had no change coupling to the rest of the codebase; participants noted that the same score in a more central component would likely have been judged differently. Likewise, in Product B, some highly flagged files were test files. Although the underlying issues were acknowledged, participants considered them less relevant and therefore lower priority than production files with similar scores. These examples show that friction was treated as a useful warning signal, but one that still required contextual prioritization.

4.1.0.4 Product context strongly shaped the meaning of friction

Participants consistently interpreted friction through the broader product and development context. Two factors were especially salient. First, because friction is partly driven by recent change frequency, it may miss files that are rarely modified but still difficult and time-consuming to change. Second, active refactoring can itself inflate friction, since files under cleanup may still have poor code health while receiving many commits. This was particularly visible in Product C and suggests that friction must be interpreted together with knowledge of ongoing work. More generally, participants emphasized that the practical relevance of friction depends on file role, whether it belongs to production or test code, its coupling to other parts of the codebase, and whether recent activity reflects routine maintenance or temporary restructuring.

4.2 RQ2: Alignment with Maintenance-Relevant Areas↩︎

To address RQ2, we examined whether files highlighted by Technical Debt Friction corresponded to areas that later proved maintenance-relevant in practice. We compared the initial CodeScene snapshot with subsequent changes in code health and friction, participants’ assessments during the interviews, and later refactoring or maintenance activity. Table 3 summarizes the main files examined, their practitioner assessment, and their observed later alignment with maintenance relevance. It reports representative friction values for selected files to provide a quantitative indication of signal strength while focusing on alignment rather than thresholds. To classify alignment between Technical Debt Friction and maintenance relevance, we used a qualitative, evidence-based scheme. Alignment was strong when practitioner recognition, technical indicators, and observed maintenance activity converged; moderate when recognition and indicators aligned but improvement evidence was limited; partial when only some evidence supported relevance; and weak or context-dependent when flagged files were judged lower priority (e.g., test code, peripheral components, or temporary spikes).

4.2.0.1 Friction often aligned with files that later received maintenance attention

Several files highlighted by friction were later refactored, improved, or remained under active maintenance. In Product A-v1, one highly flagged file (43% friction) was later refactored, reducing friction and improving code health, while another file (22% friction) was also recognized as problematic but deferred because of its low importance. In Product A-v2, one previously flagged file had been successfully refactored by the follow-up, again leading to improved code health and lower friction (e.g., from 22% to 8%). In Product C-v1, one flagged file (33% friction) had already been refactored during the observation period, reducing friction even though change activity remained high. These examples indicate that friction frequently identifies files that later become targets for improvement or remain central to ongoing maintenance work.

4.2.0.2 Alignment was strongest for central production code with persistent structural problems

Alignment was clearest when flagged files combined structural issues with architectural or functional importance. In Product A-v1, files with low code health and moderate-to-high friction (e.g., 16–19%) were considered meaningful because they were central to the product and showed bumpiness, nested complexity, and low cohesion. In Product B, a highly flagged production file (23% friction) with complex logic and frequent changes was seen as important, even if some issues were considered less severe than the metric suggested. In Product C-v1, one flagged file (45% friction) was recognized as difficult due to its size and nested conditionals and was seen as a reasonable refactoring candidate. These suggest that friction aligned most clearly with maintenance relevance when a file was both structurally problematic and central to everyday development work.

4.2.0.3 Alignment was weaker for isolated files, test files, and temporary activity spikes

High friction did not always imply high practical importance. In Product B, some flagged files were test files (e.g., 17–19% friction); although developers acknowledged their quality issues, they considered them less relevant than production files with similar scores. In Product C, one high-friction file (33% friction) was treated as lower priority because it was relatively isolated and weakly coupled to the rest of the codebase; developers noted that the same friction level in a more central component would likely have been judged differently. The sessions showed that some files were flagged because of recent bursts of activity rather than persistent maintenance bottlenecks. Thus, friction aligned less well with maintenance relevance when the flagged file was peripheral, belonged to test code, or reflected a temporary development spike. We do not interpret the lower priority given to test files as evidence that friction is less meaningful there; rather, it reflects a short-term prioritization choice, since poorly maintainable test code may still increase long-term maintenance cost by slowing validation, reducing confidence in change, and making refactoring harder to perform safely [18].

4.2.0.4 Version comparisons suggest that friction is sensitive to both refactoring and ongoing work

Comparing versions revealed both the usefulness and the limits of friction as an alignment signal. In several cases, refactoring reduced friction and improved code health (e.g., from 22% to 8% in Product A), showing that the metric can track meaningful maintenance progress. At the same time, friction could remain high, or even increase temporarily, when a file was actively being reworked. This was particularly visible in Product C-v1, where one file (initially around 33% friction) appeared to have been refactored during the observation window: friction decreased, but remained substantial because change activity stayed high. In Product A-v2, some previously flagged files remained in similar condition (e.g., low but stable friction around 3–4%), indicating persistent relevance, while others changed in ways more closely tied to ongoing work than to stable architectural problems. These observations show that friction can reflect genuine maintenance relevance over time, but is also sensitive to the timing of active development.

4.2.0.5 Context determined whether alignment translated into practical importance

Participants consistently interpreted alignment through product context rather than metric values alone. They considered whether a file belonged to production or test code, whether it was central or isolated, whether it was under refactoring, and whether recent commits reflected routine maintenance or temporary restructuring. This was clear in Product C, where the system was largely in maintenance mode and some files showed friction (e.g., 33–45%) mainly because of concentrated work by a small number of contributors. Participants emphasized that such files could still be less urgent than centrally used components with similar scores. These discussions indicate that alignment with friction was not sufficient by itself; its practical significance depended on contextual knowledge of the file’s role and the broader development situation.

4.3 RQ3: Broader Maintenance and Evolution Insights Beyond Individual Refactoring Candidates↩︎

To address RQ3, we complemented the file-level analyses from RQ1 and RQ2 with an exploratory project-level analysis of friction distributions. Instead of focusing on individual flagged files, we examined how touches were distributed across all files in the latest available versions of the studied products and related these patterns to code health. Our goal was to investigate whether project-level friction distributions can reveal broader maintenance and evolution characteristics beyond individual refactoring candidates.

Figures 2–4 show the distributions for Products A-v2, B, and C-v2, respectively. In each plot, files are ordered along the x-axis by decreasing number of touches (revisions) during the analysis period, while the y-axis shows the corresponding number of touches, revealing the distribution of recent development activity across the codebase. Each point represents a file, colored by its CodeHealth score on the 1–10 scale from red (low) to green (high). The plots thus combine the two main constituents of friction: change frequency and maintainability.

The three products exhibit clearly different distribution shapes, suggesting that project-level friction captures more than the presence of problematic files. It also reveals how maintenance and development effort is distributed across the codebase, including differences in activity concentration, spread of touched files, and the extent to which active files remain structurally healthy. At the same time, these observations remain exploratory: the current evidence supports qualitative contrasts across the studied products, while stronger claims about generality or classification require further validation.

4.3.0.1 The distributions reveal different maintenance and evolution profiles

The overall distribution shapes differ markedly across the studied products. In Figure 2, Product A-v2 shows a moderately concentrated distribution, with a small set of highly active files and a long tail of rarely touched ones. Most points are green, indicating generally healthy active code, though a few lower-CodeHealth files appear among the more frequently touched files. In Figure 3, Product B has an even broader spread of touched files, with most points remaining green (comparatively healthy code despite substantial activity). By contrast, Figure 4 shows that Product C-v2 has a much more concentrated profile, with most files receiving little or no activity and a smaller subset accounting for the visible maintenance effort. These differences suggest that project-level friction distributions can capture broader maintenance profiles rather than only local refactoring needs.

4.3.0.2 Project-level friction scores complement the visual profiles

The visual contrasts in Figures 2–4 are also reflected in the aggregate friction scores. Product A-v2 has a Dynamic Friction of 6.39 and a Total Friction of 7.49, compared with 7.69 and 9.49 for Product A-v1. This reduction is consistent with a less severe overall friction profile in the newer version. Product B has values of 7.76 and 9.16, respectively. Figure 3 shows that much of the activity occurs in comparatively healthy files. Product C-v2 has the highest scores by far—14.87 and 19.27 (from 12.71 and 16.41 for Product C-v1)—which aligns with Figure 4, where a smaller subset of files concentrates much of the visible maintenance effort and lower CodeHealth values are more prominent. The friction scores reinforce the qualitative interpretation of the figures by showing clear differences in the magnitude of friction burden across the studied products.

4.3.0.3 The figures suggest different degrees of activity concentration

In Product C-v2 (Figure 4), a long flat region near the x-axis shows that most files are touched rarely, while only a limited subset receives notable attention. This pattern is consistent with a product in a more maintenance-oriented mode, where activity is concentrated in selected parts of the codebase. By contrast, Product B (Figure 3) shows a much broader spread of files with non-trivial activity, suggesting more widely distributed evolution work. Product A-v2 (Figure 2) lies between these two cases, with broader activity than Product C but a more concentrated profile than Product B, while remaining largely healthy overall. These contrasts suggest that project-level friction distributions may help distinguish between concentrated maintenance effort and more broadly distributed development activity.

4.3.0.4 Code Health adds interpretive value beyond activity alone

The distributions become more informative when activity is interpreted together with Code Health. Because the figures encode Code Health through color, they show not only which files are active, but also whether that activity is concentrated in healthier or more problematic parts of the codebase. This is especially useful when comparing Products A-v2 and B: both show broad activity, but Figure 2 suggests a somewhat more concentrated activity profile for A-v2, while Figure 3 is more broadly distributed and remains dominated by green points. This points to two different maintenance situations: one in which activity is more concentrated, though still largely healthy overall, and another in which activity is more broadly distributed while the code remains healthy. Product C-v2 (Figure 4) adds that limited overall activity can still coexist with a smaller set of files that continue to attract maintenance effort. Thus, the project-level view is useful because it combines where activity occurs with an indication of the quality of the files involved.

4.3.0.5 Project-level friction broadens the analytical role of friction

The project-level perspective provides insights beyond individual refactoring candidates. While file-level friction is mainly useful for locating specific inspection or refactoring targets, the distributions in Figures 2–4 reveal broader properties of the maintenance landscape, such as whether work is concentrated or widespread, whether frequent changes accumulate in healthier or weaker code, and whether the overall profile is more consistent with active evolution or selective maintenance. Project-level friction broadens the role of friction from local prioritization to higher-level characterization of how maintenance effort is distributed across a product.

4.3.0.6 The observed differences are promising, but the claims should remain bounded

Although the contrasts between Figures 2–4 are clear, the current evidence supports only bounded conclusions. The figures show that the studied products exhibit different friction-distribution shapes that plausibly align with their development contexts. However, stronger claims—such as reliably distinguishing lifecycle stage, maintenance mode, or project class—require additional support through a formal summary measure, systematic comparison across products or versions, and a broader evaluation set.

5 Cross-case Discussion↩︎

The RQ findings show that Technical Debt Friction is best understood not as a standalone metric, but as a maintenance-oriented decision-support concept whose usefulness depends on context, supporting evidence, and practitioner interpretation. Table 4 presents the detailed cross-case patterns observed across the products. In the discussion below, we synthesize these patterns into five higher-level cross-case insights (Sections 5.1–5.5). Rather than repeating the RQ results, this section discusses what the combined findings imply for how Technical Debt Friction should be interpreted and used in practice across products, contexts, and levels of analysis.

5.1 Friction as an Integrative and Context-Sensitive Concept↩︎

Practitioners engaged with friction as an integrative concept. Across all products, it became meaningful when discussed together with code health, hotspots, change coupling, refactoring-oriented views, and, where available, socio-technical information. Its value therefore lies less in introducing a new signal than in combining several maintenance-relevant signals into a single maintenance-oriented perspective.

At the same time, friction is inherently context-sensitive. Its meaning depends on factors such as file role, architectural centrality, coupling, maintenance mode, and ongoing work. Practitioners did not treat flagged files as important based on friction alone, but interpreted them in context (e.g., production vs. test, central vs. isolated, persistent vs. temporary activity). Thus, friction is most useful when supporting contextual interpretation rather than as a universal signal of importance.

A key example is the distinction between test and application code. Practitioners sometimes treated friction in test files as less urgent, even when problematic. This does not mean the signal is less meaningful; rather, it reflects short-term prioritization where delivery concerns outweigh long-term maintainability. In practice, poorly maintainable test code can still slow validation, complicate regression analysis, reduce confidence in change, and increase future refactoring costs. Discounting test-code friction may therefore indicate hidden maintenance burden rather than a flaw in the signal.

5.2 Friction Bridges Diagnosis and Prioritization↩︎

Friction helps bridge the gap between diagnosis and prioritization. Existing software analytics often provide valuable but fragmented views of structural weaknesses, development activity, coupling, or team-related risks. Across the cases, practitioners used friction to connect these views to the more practical question of where attention might be warranted. This did not replace prioritization judgment: practitioners still distinguished between immediately relevant files, plausible but lower-priority files, and files whose scores reflected temporary or peripheral conditions. However, friction helped focus attention and structure the discussion around whether the improvement effort might be justified. It narrowed the search space of concern rather than automating the final decision.

5.3 The Importance of Time and Ongoing Activity↩︎

Friction must be interpreted in relation to development timing. The version comparisons and follow-up observations showed that friction may reflect both persistent maintenance burden and active remediation. In some cases, refactoring reduced friction and improved code health; in others, friction remained elevated during active cleanup because changes continued while quality improved more slowly. High friction may therefore indicate either accumulated burden or ongoing work intended to reduce it. This temporal sensitivity reinforces that friction should not be read statically or independently of current development activity, but interpreted with knowledge of whether a component is being actively reworked, stabilized, or only occasionally modified.

5.4 Project-Level Characterization↩︎

The project-level analysis suggests that friction can support more than identifying individual refactoring candidates by showing how maintenance effort is distributed across a product. The studied products exhibited different distribution shapes, indicating varying degrees of activity concentration versus spread across the codebase, which may help distinguish between concentrated maintenance effort and more distributed development activity. The plots also show that activity is more informative when interpreted with code health, revealing whether work accumulates in healthier or more problematic parts of the system. At the same time, this broader use remains exploratory: although the contrasts were meaningful and consistent with development contexts, stronger claims about lifecycle characterization or comparative ranking require further quantitative validation. Project-level friction should therefore be seen as a promising exploratory indicator rather than a validated benchmarking measure.

5.5 Usefulness for Discussion, Not Automatic Ranking↩︎

Friction appears more useful for structured maintenance discussion than for automatic ranking. Across products, practitioners used it as a starting point for inspection and reflection, not as a self-sufficient answer to what should be done next. Even when flagged files aligned with known problematic areas, contextual and architectural understanding remained necessary before deciding whether a file truly warranted refactoring or maintenance attention.

5.6 Implications↩︎

These findings suggest three implications. First, Technical Debt Friction should be treated as a context-sensitive concept for reasoning about accumulated maintenance burden, not as a universally interpretable score. Second, its practical value lies in connecting fragmented software analytics to maintenance prioritization and communication. Third, effective use of friction requires supporting evidence and human judgment, especially when flagged files differ in role, centrality, or development timing. Overall, the combined findings indicate that friction is promising as an industrial maintenance concept because it helps practitioners reason not only about where code is problematic, but also about where the system resists change in ways that matter for development work.

6 Threats to Validity↩︎

Construct validity. A key threat is the interpretation of Technical Debt Friction, which combines technical and socio-technical aspects and may be understood differently by practitioners. The study also relies on CodeScene’s operationalization of friction and related views. We mitigated this by grounding discussions in concrete artifacts and interpreting friction with complementary analyses rather than in isolation.

Internal validity. The sessions may have been influenced by interviewer framing, presentation order, or participants’ prior beliefs. As a walkthrough-based study, confirmation bias and selective attention cannot be excluded. We mitigated this through a shared interview protocol, multiple cases, and discussion of both confirming and disconfirming examples.

External validity. The study covers three industrial products (two with multiple versions) and may not generalize to all systems, domains, or organizations. The usefulness of friction may depend on factors such as system size, architecture, maintenance mode, and team structure. We interpret the findings as evidence of practical relevance in the studied settings rather than universally generalizable conclusions.

Reliability. As in many exploratory industrial studies, the analysis involves researcher interpretation of practitioner discussions. We mitigated this through explicit research questions, a shared interview protocol, and grounding findings in concrete examples and version comparisons. Nevertheless, some subjectivity remains unavoidable.

7 Related Work↩︎

Our work relates to research on technical debt [19]–[21], maintenance prioritization [22], [23], refactoring support [24], [25], and socio-technical software evolution [26], [27]. Technical debt describes how short-term compromises increase future maintenance cost and complicate evolution [19]. Prior work shows that the challenge is not only to identify debt, but also to understand how it creates development friction and affects productivity [9], and that prioritization depends on developer judgment, context, and organizational tradeoffs rather than a single technical indicator [28]–[34]. Building on this, we focus on technical debt friction as a practice-oriented lens for identifying where technical debt most strongly impacts ongoing maintenance and evolution.

A second line of work has shown that software analytics can support maintenance and refactoring decisions [35], [36]. Code churn and related evolutionary signals help identify change-prone components [3], [37], while mining version histories reveals change coupling and hidden maintenance dependencies between artifacts [4], [38]. Other work has combined code quality and development activity to identify parts of the system that deserve attention, which is closely related to hotspot-based reasoning [39]. Refactoring studies likewise show that improvement decisions are selective and shaped by expected benefit, available tool support, and practical constraints rather than by structural quality considerations alone [2], [40]–[45]. Recent work on technical debt prioritization and automation also confirms continuing industrial interest in methods and tools that help rank debt items and guide action, while highlighting that actionability remains a central challenge [28], [29], [46], [47], [47], [48]. In contrast to prior work that studies individual signals or automation mechanisms in isolation, our paper investigates whether practitioners find technical debt friction meaningful and useful as an integrative decision-support concept across real industrial cases.

Maintenance burden is not purely technical; ownership, expertise concentration, and coordination also influence software quality and productivity [5], [7], [49]. This socio-technical perspective matters because many maintenance problems arise from the interplay of technical dependencies and organizational conditions rather than isolated code properties [5], [7], [50]. Our study complements this work by examining whether practitioners recognize technical debt friction as a way to interpret these combined effects when reasoning about maintenance pain points and prioritization.

8 Conclusion↩︎

This paper presented a multi-case industrial study of technical debt friction in real software development contexts. We examined how practitioners interpret the concept, how friction-related analyses align with maintenance-relevant areas, and whether project-level friction distributions can provide broader maintenance and evolution insights.

Our findings show that practitioners generally regarded technical debt friction as a useful indicator of maintenance burden, but not as a standalone signal. At file level, it often aligned with known problematic areas and, in several cases, with files that later received maintenance or refactoring attention, although its relevance depended strongly on context, such as file role, architectural centrality, and ongoing activity. At project level, the exploratory analysis suggests that friction distributions may reveal broader maintenance and evolution patterns, though these require further quantitative validation.

Acknowledgment↩︎

This paper has received funding from the Research Council of Norway’s Innovation Project for the Industrial Sector (IPN) Programme under grant agreement for project No. 340991 (TechDebtOps) and the Competence Centre NextG2Com funded by the VINNOVA program for Advanced Digitalisation with grant number 2023-00541.

References↩︎