Pith. sign in

REVIEW 3 major objections 2 minor 50 references

Technical Debt Friction for Maintenance Prioritization: An Industrial Multi-Case Study

T0 review · 3 major / 2 minor · reviewed 2026-07-03 · grok-4.3

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read Technical debt friction helps identify where maintenance burden is highest when read alongside code health and socio-technical data.

desk verdict Practitioners said friction helped with maintenance reasoning in these sessions, but the study does not isolate its value from the other analytics shown at the same time. read the letter →

arxiv 2607.01850 v1 pith:B4KEA3XF submitted 2026-07-02 cs.SE

Simeon Tverdal , Phu Nguyen , Arda Goknil , Antonio Martini , Markus Borg , Adam Tornhill This is my paper · ORCID
classification cs.SE
keywords technicaldebtmaintenanceprioritizationindustrialcasestudysoftwareevolutionrefactoringcodehealthsocio-technicalanalysis
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper examines whether technical debt friction can serve as a practical signal for deciding which parts of a software system deserve maintenance or refactoring attention. It reports that practitioners in several industrial cases viewed friction as useful for reasoning about experienced change burden, particularly when the friction view was combined with existing code metrics and team-structure information. The study uses structured walkthrough sessions to check whether friction scores line up with known pain points and with files that later received maintenance work. At the project level the authors also explore whether friction distributions point to wider evolution patterns. The core suggestion is that friction offers a decision-support lens that gains value when kept in context rather than used in isolation.

What carries the argument

Technical debt friction, a measure of the experienced burden of change caused by technical debt, used to rank maintenance candidates and to surface broader evolution patterns when examined with complementary technical and socio-technical views.

What would settle it

A follow-up industrial case in which friction scores show no consistent alignment with practitioner-identified pain points or with files chosen for later maintenance would undermine the usefulness claim.

Watch

Extended reading notes

Core claim

Technical debt friction functions as a prioritization-oriented concept that surfaces locations where technical debt most strongly slows maintenance and evolution; practitioners judged the concept useful when friction analysis was interpreted together with code health, hotspots, coupling, and socio-technical views, and file-level friction often matched known problematic areas and later maintenance activity.

Load-bearing premise

Structured walkthrough sessions with practitioners give an unbiased and accurate picture of how well friction analysis matches actual maintenance pain and refactoring needs.

Editorial extensions

If this is right

  • At the file level, friction frequently coincides with areas already known to be problematic and with files that later receive maintenance attention.
  • Friction analysis gains practical relevance only when read together with code health, coupling, and socio-technical information.
  • Project-level friction distributions can expose wider maintenance and evolution patterns beyond single refactoring targets.
  • Friction works best as a supporting signal rather than a standalone ranking method.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Friction could be computed automatically from existing code and commit data and then surfaced inside standard developer dashboards.
  • Teams might use friction distributions to decide how to allocate limited refactoring resources across an entire codebase rather than only at the file level.
  • The approach may transfer to other maintenance-related decisions such as test-effort allocation or architectural review scheduling.
  • Longer-term studies could test whether sustained use of friction views changes the rate at which technical debt accumulates.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit.

Referee Report

3 major / 2 minor

Summary. The manuscript reports a multi-case industrial study of 'technical debt friction' as a prioritization concept. Structured walkthrough sessions were conducted with practitioners across cases, presenting friction artifacts alongside code health, hotspots, coupling, refactoring targets, and socio-technical views. The central claims are that practitioners generally found friction useful for reasoning about maintenance burden (especially in combination with other views), that file-level friction often aligned with known problematic areas and in several cases with later maintenance attention, and that project-level friction distributions may reveal broader evolution patterns.

Significance. If the methodological gaps are closed, the work offers relevant empirical grounding for a practitioner-oriented TD concept in real industrial settings. The multi-case design and explicit combination of technical and socio-technical views are strengths that could help move TD research toward decision-support tools rather than isolated metrics. The exploratory project-level analysis is a modest but useful extension beyond single-file refactoring candidates.

major comments (3)
  1. [§3] §3 (Research Method): The paper supplies no details on session protocols, participant selection criteria, how feedback was recorded or coded, or any pre-session baseline measures. Because the usefulness and alignment claims rest entirely on practitioner interpretations elicited during these sessions, the absence of these elements is load-bearing for the central empirical claims.
  2. [§4] §4 (Findings) and Abstract: Statements that friction 'often aligned with known problematic areas' and 'in several cases' with later maintenance attention are presented without counts, case-by-case mapping, or independent triangulation against maintenance logs. This makes it impossible to evaluate the strength or consistency of the reported alignments.
  3. [§4.2] §4.2 (Project-level analysis): The suggestion that friction distributions reveal broader maintenance patterns is introduced as exploratory but lacks any description of the aggregation method, statistical or visual criteria used, or comparison against null models, rendering the claim difficult to assess or replicate.
minor comments (2)
  1. [Abstract] The abstract and introduction could more clearly distinguish the incremental contribution of friction from the complementary views that were shown simultaneously in every session.
  2. Table or figure captions for the analysis artifacts should explicitly state the time window between the friction computation and the 'later maintenance attention' observations.

Simulated Author's Rebuttal

3 responses · 0 unresolved

We thank the referee for the constructive and detailed comments, which help strengthen the methodological transparency and precision of our claims. We address each major comment point by point below, indicating planned revisions to the manuscript.

read point-by-point responses

  1. Referee: [§3] §3 (Research Method): The paper supplies no details on session protocols, participant selection criteria, how feedback was recorded or coded, or any pre-session baseline measures. Because the usefulness and alignment claims rest entirely on practitioner interpretations elicited during these sessions, the absence of these elements is load-bearing for the central empirical claims.

    Authors: We agree that additional methodological detail is required. In the revised manuscript we will expand §3 to describe the session protocols (structured walkthroughs of 60-90 minutes presenting artifacts in a consistent sequence), participant selection criteria (practitioners with maintenance responsibilities and at least two years on the respective projects, drawn from the partner companies), recording of feedback (contemporaneous notes taken by two researchers with post-session summaries), and the absence of pre-session baseline measures (the study being exploratory). These additions will improve evaluability of the elicited interpretations. revision: yes

  2. Referee: [§4] §4 (Findings) and Abstract: Statements that friction 'often aligned with known problematic areas' and 'in several cases' with later maintenance attention are presented without counts, case-by-case mapping, or independent triangulation against maintenance logs. This makes it impossible to evaluate the strength or consistency of the reported alignments.

    Authors: The reported alignments are based on practitioner feedback during the sessions and are therefore qualitative. We will revise §4 and the abstract to include more explicit per-case mappings of discussed files where confidentiality permits, while retaining the cautious phrasing. Independent triangulation against maintenance logs was not performed owing to restricted access to historical change data in the industrial settings; we will state this limitation explicitly and discuss its implications for the strength of the alignment claims. revision: partial

  3. Referee: [§4.2] §4.2 (Project-level analysis): The suggestion that friction distributions reveal broader maintenance patterns is introduced as exploratory but lacks any description of the aggregation method, statistical or visual criteria used, or comparison against null models, rendering the claim difficult to assess or replicate.

    Authors: The project-level analysis is explicitly exploratory. We will augment §4.2 with a description of the aggregation procedure (summing normalized friction scores across files per project), the visual criteria employed (inspection of distribution plots for variance and outliers), and an explicit statement that no statistical tests or null-model comparisons were applied, as the goal is to surface candidate patterns for subsequent research rather than to confirm hypotheses. revision: yes

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: empirical qualitative study with no derivations or fitted constructs

full rationale

The paper is a multi-case industrial study relying on structured walkthrough sessions and practitioner interpretations. It contains no equations, parameters, or mathematical derivations that could reduce to inputs by construction. Central claims rest on direct session feedback rather than self-citation chains, uniqueness theorems, or ansatz smuggling. No load-bearing steps match the enumerated circularity patterns; the work is self-contained as an empirical investigation against external practitioner benchmarks.

Assumptions & free parameters 0 free parameters · 0 assumptions · 0 invented entities

No mathematical content; the study is purely empirical and introduces no free parameters, axioms, or invented entities.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Technical Debt Friction for Maintenance Prioritization: An Industrial Multi-Case Study." pith.science (2026). https://pith.science/paper/B4KEA3XF

@misc{pith2026260701850,
  author       = {Pith},
  title        = {Pith review of: Technical Debt Friction for Maintenance Prioritization: An Industrial Multi-Case Study},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/B4KEA3XF}},
  note         = {Machine review of arXiv:2607.01850}
}
read the original abstract

Software-intensive organizations need effective ways to identify where maintenance and refactoring efforts will yield the greatest practical benefit. Although software analytics such as code health, hotspots, and coupling provide valuable signals, they do not always capture the experienced burden of change that slows software evolution in practice. This paper presents a multi-case industrial study of technical debt friction as a prioritization-oriented concept for identifying where technical debt most strongly affects maintenance and evolution. We investigate how practitioners interpret the concept, whether friction-related analysis aligns with perceived maintenance pain points and refactoring needs, and what broader maintenance and evolution insights friction can provide beyond individual refactoring candidates. To this end, we conducted structured walkthrough sessions with practitioners across multiple industrial cases using analysis artifacts including code health, hotspots, coupling, refactoring targets, and socio-technical views. Our findings show that practitioners generally considered technical debt friction useful for reasoning about maintenance burden, especially when interpreted together with complementary technical and socio-technical views. At the file level, friction often aligned with known problematic areas and, in several cases, with files that later received maintenance attention, although its practical relevance depended strongly on context. In addition, our exploratory project-level analysis suggests that friction distributions may reveal broader maintenance and evolution patterns. These results indicate that technical debt friction is promising as a decision-support concept, but most effective when used with contextual knowledge and supporting evidence.

Figures

Figures reproduced from arXiv: 2607.01850 by the authors.

Figure 1
Figure 1. Example technical debt friction view in CodeScene. It highlights parts [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. Project-level friction distribution for Product A-v2. It plots the number [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 4
Figure 4. Project-level friction distribution for Product C-v2. It shows that most [PITH_FULL_IMAGE:figures/full_fig_p007_4.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

50 extracted references · 50 canonical work pages

  1. [1]

    An empirical study of software developers’ management of dependencies and changes,

    C. R. De Souza and D. F. Redmiles, “An empirical study of software developers’ management of dependencies and changes,” inProceedings of the 30th international conference on Software engineering, 2008, pp. 241–250

    work page 2008

  2. [2]

    A field study of refactoring challenges and benefits,

    M. Kim, T. Zimmermann, and N. Nagappan, “A field study of refactoring challenges and benefits,” inProceedings of the ACM SIGSOFT 20th international symposium on the foundations of software engineering, 2012, pp. 1–11

    work page 2012

  3. [3]

    Use of relative code churn measures to predict system defect density,

    N. Nagappan and T. Ball, “Use of relative code churn measures to predict system defect density,” inProceedings of the 27th international conference on Software engineering, 2005, pp. 284–292

    work page 2005

  4. [4]

    Mining version histories to guide software changes,

    T. Zimmermann, A. Zeller, P. Weissgerber, and S. Diehl, “Mining version histories to guide software changes,”IEEE Transactions on software engineering, vol. 31, no. 6, pp. 429–445, 2005

    work page 2005

  5. [5]

    Don’t touch my code! examining the effects of ownership on software quality,

    C. Bird, N. Nagappan, B. Murphy, H. Gall, and P. Devanbu, “Don’t touch my code! examining the effects of ownership on software quality,” inProceedings of the 19th ACM SIGSOFT symposium and the 13th European conference on Foundations of software engineering, 2011, pp. 4–14

    work page 2011

  6. [6]

    Combining insights from multiple tools to manage technical debt in industrial c# projects,

    S. Tverdal, P. Nguyen, A. Goknil, A. Martini, M. Astekin, M. Orucevic, M. M. Kruke, and H. Stranden, “Combining insights from multiple tools to manage technical debt in industrial c# projects,” in2025 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2025, pp. 709–720

    work page 2025

  7. [7]

    Socio-technical con- gruence: a framework for assessing the impact of technical and work dependencies on software development productivity,

    M. Cataldo, J. D. Herbsleb, and K. M. Carley, “Socio-technical con- gruence: a framework for assessing the impact of technical and work dependencies on software development productivity,” inProceedings of the Second ACM-IEEE international symposium on Empirical software engineering and measurement, 2008, pp. 2–11

    work page 2008

  8. [8]

    Technical debt — codescene documentation,

    CodeScene, “Technical debt — codescene documentation,” https:// codescene.io/docs/guides/technical/hotspots.html, 2026, accessed: 2026- 04-23

    work page 2026

Show all 50 references
  1. [9]

    Reducing friction in software development,

    P. Avgeriou, P. Kruchten, R. L. Nord, I. Ozkaya, and C. Seaman, “Reducing friction in software development,”Ieee software, vol. 33, no. 1, pp. 66–73, 2015

    2015

  2. [10]

    Detecting technical debt in source code changes using large language models,

    M. Astekin, A. Goknil, S. Sen, S. Tverdal, and P. Nguyen, “Detecting technical debt in source code changes using large language models,” inInternational Conference on Product-Focused Software Process Im- provement. Springer, 2025, pp. 334–352

    2025

  3. [11]

    CodeScene, https://codescene.com/, Visited in 2026

    2026

  4. [12]

    Code Red: The Business Impact of Code Quality - A Quantitative Study of 39 Proprietary Production Codebases,

    A. Tornhill and M. Borg, “Code Red: The Business Impact of Code Quality - A Quantitative Study of 39 Proprietary Production Codebases,” inProc. of the 5th International Conference on Technical Debt, 2022, pp. 11–20

    2022

  5. [13]

    Increasing, Not Diminishing: Investigating the Returns of Highly Maintainable Code,

    M. Borg, I. Pruvost, E. Mones, and A. Tornhill, “Increasing, Not Diminishing: Investigating the Returns of Highly Maintainable Code,” inProc. of the 7th International Conference on Technical Debt, 2024, pp. 21–30

    2024

  6. [14]

    Ghost echoes revealed: Benchmarking maintainability metrics and machine learning predictions against human assessments,

    M. Borg, M. Ezzouhri, and A. Tornhill, “Ghost echoes revealed: Benchmarking maintainability metrics and machine learning predictions against human assessments,” in2024 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2024, pp. 678– 688

    2024

  7. [15]

    ismell: Assembling llms with expert toolsets for code smell detection and refactoring,

    D. Wu, F. Mu, L. Shi, Z. Guo, K. Liu, W. Zhuang, Y . Zhong, and L. Zhang, “ismell: Assembling llms with expert toolsets for code smell detection and refactoring,” inProceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’24. New Y...

    2024 doi

  8. [16]

    Case study research: design and methods (ver. ed.),

    R. YIN, “Case study research: design and methods (ver. ed.),”Newbury Park, CA: Stage, 1989

    1989

  9. [17]

    Recommended steps for thematic synthesis in software engineering,

    D. S. Cruzes and T. Dyba, “Recommended steps for thematic synthesis in software engineering,” in2011 international symposium on empirical software engineering and measurement. IEEE, 2011, pp. 275–284

    2011

  10. [18]

    Smells in software test code: A survey of knowledge in industry and academia,

    V . Garousi and B. K ¨uc ¸¨uk, “Smells in software test code: A survey of knowledge in industry and academia,”Journal of Systems and Software, vol. 138, pp. 52–81, Apr. 2018

    2018

  11. [19]

    Technical debt: From metaphor to theory and practice,

    P. Kruchten, R. L. Nord, and I. Ozkaya, “Technical debt: From metaphor to theory and practice,”Ieee software, vol. 29, no. 6, pp. 18–21, 2012

    2012

  12. [20]

    A systematic mapping study on technical debt and its management,

    Z. Li, P. Avgeriou, and P. Liang, “A systematic mapping study on technical debt and its management,”Journal of Systems and Software, vol. 101, pp. 193–220, 2015

    2015

  13. [21]

    Managing technical debt,

    E. Allman, “Managing technical debt,”Communications of the ACM, vol. 55, no. 5, pp. 50–55, 2012

    2012

  14. [22]

    Software maintenance and evolution: a roadmap,

    K. H. Bennett and V . T. Rajlich, “Software maintenance and evolution: a roadmap,” inProceedings of the Conference on the Future of Software Engineering, 2000, pp. 73–87

    2000

  15. [23]

    B. P. Lientz and E. B. Swanson,Software maintenance management. Addison-Wesley Longman Publishing Co., Inc., 1980

    1980

  16. [24]

    A survey of software refactoring,

    T. Mens and T. Tourw ´e, “A survey of software refactoring,”IEEE Transactions on software engineering, vol. 30, no. 2, pp. 126–139, 2004

    2004

  17. [25]

    Automatic software refactoring: a systematic literature review,

    A. A. B. Baqais and M. Alshayeb, “Automatic software refactoring: a systematic literature review,”Software Quality Journal, vol. 28, no. 2, pp. 459–502, 2020

    2020

  18. [26]

    An ecosystemic and socio-technical view on software main- tenance and evolution,

    T. Mens, “An ecosystemic and socio-technical view on software main- tenance and evolution,” in2016 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2016, pp. 1– 8

    2016

  19. [27]

    Socio-technical grounded theory for software engineering,

    R. Hoda, “Socio-technical grounded theory for software engineering,” IEEE Transactions on Software Engineering, vol. 48, no. 10, pp. 3808– 3832, 2021

    2021

  20. [28]

    Technical debt prioritization: a developer’s perspective,

    D. Pina, C. Seaman, and A. Goldman, “Technical debt prioritization: a developer’s perspective,” inProceedings of the international conference on technical debt, 2022, pp. 46–55

    2022

  21. [29]

    Technical debt mon- itoring decision making with skin in the game,

    S. Fungprasertkul, R. Bahsoon, and R. Kazman, “Technical debt mon- itoring decision making with skin in the game,”ACM Transactions on Software Engineering and Methodology, vol. 33, no. 7, pp. 1–27, 2024

    2024

  22. [30]

    A sys- tematic literature review of technical debt prioritization,

    R. Alfayez, W. Alwehaibi, R. Winn, E. Venson, and B. Boehm, “A sys- tematic literature review of technical debt prioritization,” inProceedings of the 3rd international conference on technical debt, 2020, pp. 1–10

    2020

  23. [31]

    A systematic literature review on technical debt prioritization: Strategies, processes, factors, and tools,

    V . Lenarduzzi, T. Besker, D. Taibi, A. Martini, and F. A. Fontana, “A systematic literature review on technical debt prioritization: Strategies, processes, factors, and tools,”Journal of Systems and Software, vol. 171, p. 110827, 2021

    2021

  24. [32]

    Technical debt prioritization: Taxonomy, methods results, and practical characteristics,

    D. Pina, A. Goldman, and G. Tonin, “Technical debt prioritization: Taxonomy, methods results, and practical characteristics,” in2021 47th Euromicro Conference on Software Engineering and Advanced Applica- tions (SEAA). IEEE, 2021, pp. 206–213

    2021

  25. [33]

    Tracy: A business-driven technical debt prioritization framework,

    R. R. De Almeida, C. Treude, and U. Kulesza, “Tracy: A business-driven technical debt prioritization framework,” in2019 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2019, pp. 181–185

    2019

  26. [34]

    On the value of a prioritization scheme for resolving self-admitted technical debt,

    S. Mensah, J. Keung, J. Svajlenko, K. E. Bennin, and Q. Mi, “On the value of a prioritization scheme for resolving self-admitted technical debt,”Journal of Systems and Software, vol. 135, pp. 37–54, 2018

    2018

  27. [35]

    An empirical study on release-wise refactoring patterns,

    S. Noei, H. Li, and Y . Zou, “An empirical study on release-wise refactoring patterns,”Proceedings of the ACM on Software Engineering, vol. 2, no. FSE, pp. 403–424, 2025

    2025

  28. [36]

    An empirical study on maintainable method size in java,

    S. A. Chowdhury, G. Uddin, and R. Holmes, “An empirical study on maintainable method size in java,” inProceedings of the 19th International Conference on Mining Software Repositories, 2022, pp. 252–264

    2022

  29. [37]

    The good, the bad, and the monstrous: Predicting highly change-prone source code methods at their inception,

    S. Chowdhury, “The good, the bad, and the monstrous: Predicting highly change-prone source code methods at their inception,”ACM Transactions on Software Engineering and Methodology, vol. 34, no. 7, pp. 1–29, 2025

    2025

  30. [38]

    Exploring the architectural impact of possible dependencies in python software,

    W. Jin, Y . Cai, R. Kazman, G. Zhang, Q. Zheng, and T. Liu, “Exploring the architectural impact of possible dependencies in python software,” inProceedings of the 35th IEEE/ACM International Conference on Automated Software Engineering, 2020, pp. 758–770

    2020

  31. [39]

    Monitoring code quality and development activity by software maps,

    J. Bohnet and J. D ¨ollner, “Monitoring code quality and development activity by software maps,” inProceedings of the 2nd Workshop on Managing Technical Debt, 2011, pp. 9–16

    2011

  32. [40]

    Refactoring tools: Fitness for purpose,

    E. Murphy-Hill and A. P. Black, “Refactoring tools: Fitness for purpose,” IEEE software, vol. 25, no. 5, pp. 38–44, 2008

    2008

  33. [41]

    Industry’s cry for tools that support large-scale refactor- ing,

    J. Ivers, R. L. Nord, I. Ozkaya, C. Seifried, C. S. Timperley, and M. Kessentini, “Industry’s cry for tools that support large-scale refactor- ing,” inProceedings of the 44th International Conference on Software Engineering: Software Engineering in Practice, 2022, pp. 163–164

    2022

  34. [42]

    A metrics-based approach for selecting among various refactor- ing candidates,

    N. Nikolaidis, N. Mittas, A. Ampatzoglou, D. Feitosa, and A. Chatzige- orgiou, “A metrics-based approach for selecting among various refactor- ing candidates,”Empirical Software Engineering, vol. 29, no. 1, p. 25, 2024

    2024

  35. [43]

    How we refactor, and how we know it,

    E. Murphy-Hill, C. Parnin, and A. P. Black, “How we refactor, and how we know it,”IEEE Transactions on Software Engineering, vol. 38, no. 1, pp. 5–18, 2011

    2011

  36. [44]

    One thousand and one stories: a large-scale survey of software refactoring,

    Y . Golubev, Z. Kurbatova, E. A. AlOmar, T. Bryksin, and M. W. Mkaouer, “One thousand and one stories: a large-scale survey of software refactoring,” inProceedings of the 29th ACM joint meeting on european software engineering conference and symposium on the foundations of sof...

    2021

  37. [45]

    Barriers to refactoring,

    E. Tempero, T. Gorschek, and L. Angelis, “Barriers to refactoring,” Communications of the ACM, vol. 60, no. 10, pp. 54–61, 2017

    2017

  38. [46]

    Priortd: a method for prioritization technical debt,

    T. Detofeno, A. Malucelli, and S. Reinehr, “Priortd: a method for prioritization technical debt,” inProceedings of the XXXVI Brazilian symposium on software engineering, 2022, pp. 230–240

    2022

  39. [47]

    Technical debt management automation: State of the art and future perspectives,

    J. P. Biazotto, D. Feitosa, P. Avgeriou, and E. Y . Nakagawa, “Technical debt management automation: State of the art and future perspectives,” Information and Software Technology, vol. 167, p. 107375, 2024

    2024

  40. [48]

    A practical approach for technical debt prioritization based on class-level forecasting,

    D. Tsoukalas, M. Siavvas, D. Kehagias, A. Ampatzoglou, and A. Chatzi- georgiou, “A practical approach for technical debt prioritization based on class-level forecasting,”Journal of Software: Evolution and Process, vol. 36, no. 4, p. e2564, 2024

    2024

  41. [49]

    Maintenance operations on cloud, edge, and iot environments: Taxonomy, survey, and research challenges,

    P. Souza, T. Ferreto, and R. Calheiros, “Maintenance operations on cloud, edge, and iot environments: Taxonomy, survey, and research challenges,”ACM Computing Surveys, vol. 56, no. 10, pp. 1–38, 2024

    2024

  42. [50]

    Cultural and socio-technical aspects in software de- velopment,

    S. Lambiase, “Cultural and socio-technical aspects in software de- velopment,” inProceedings of the 28th International Conference on Evaluation and Assessment in Software Engineering, 2024, pp. 482– 487

    2024

Pith tools

Reviewed July 3, 2026 · model on record in the stance chip above.