Pith. sign in

REVIEW 4 major objections 6 minor 1 cited by

Tracing the Lifecycle of Architecture Technical Debt in Software Systems: A Dependency Approach

T0 review · 4 major / 6 minor · reviewed 2026-08-10 · deepseek-v4-flash

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

Pith's one-line read Repaying architectural debt raises class connectivity, study finds

desk verdict A solid proof-of-concept with a real replication package, but the headland claim is undermined by survivor bias in the unpaired comparison and the abstract overstates the negligible effect sizes. read the letter →

arxiv 2501.15387 v2 pith:3R6GFXWK submitted 2025-01-26 cs.SE

Edi Sutoyo , Paris Avgeriou , Andrea Capiluppi This is my paper · ORCID
classification cs.SE
keywords architecturaltechnicaldebtself-admitteddependencyanalysisFAN-INFAN-OUTsoftwaremaintainabilityrepositoryminingempiricalengineering
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

This paper sets out to trace how architectural technical debt (ATD) changes a software system from the moment it is introduced to the moment it is repaid, using class-level dependency counts as the measuring instrument. The authors claim that repaying ATD increases class connectivity: average FAN-IN rises 57.5% and FAN-OUT 26.7% between introduction and payment, which they read as dependency centralization that can add architectural complexity even while improving short-term quality. They also claim ATD-affected files are modified less often than comparable non-ATD files, with an average of 6.98 changes per file versus 16.12. The study is explicitly a proof of concept on 18 carefully validated ATD items, and it reports that the effect sizes are small, with Cliff's delta below 0.15 for both metrics.

What carries the argument

The argument is carried by FAN-IN and FAN-OUT, two dependency metrics that count, respectively, how many classes depend on a given class and how many classes that class depends on. The lifecycle is reconstructed with git blame to find the introduction commit and the payment commit for each of 18 validated "violation of modularity" ATD items, then static analysis (Understand) recomputes the metrics at both historical states. Mann-Whitney U tests and Cliff's delta quantify whether the connectivity distributions differ and by how much.

What would settle it

Run the same FAN-IN and FAN-OUT measurements on a matched set of at least 100 ATD repayment commits and a control set of commits matched on file size and age; if the average FAN-IN increase for ATD files is not larger than the control's, the centralization claim is refuted. Even within the current 18 items, computing the change for files matched by SLOC at introduction would test whether the effect survives size normalization.

Watch

Extended reading notes

Core claim

The central discovery, stated on the paper's own terms, is that the repayment phase of architectural technical debt is visible in dependency structure: files touched by ATD repayment gain incoming dependencies (FAN-IN) by 57.5% on average and outgoing dependencies (FAN-OUT) by 26.7%, with medians shifting upward and Mann-Whitney U tests rejecting identical distributions over the full sample. Because the effect sizes are negligible by Cliff's delta (0.1028 for FAN-IN, 0.1213 for FAN-OUT), the authors describe the structural impact as modest rather than dramatic. They additionally find that ATD files change less often than non-ATD files and that, controlling for lines of code, change frequency correlates positively with FAN-IN and FAN-OUT in ATD files but negatively with cyclomatic complexity.

Load-bearing premise

The load-bearing premise is that the 18 filtered items are genuine architectural debt instances and that the git-blame-identified introduction and payment commits actually mark the debt's lifecycle rather than ordinary code evolution; the paper's own Non-ATD control, which shows larger dependency increases, is evidence this premise can fail.

Editorial extensions

If this is right

  • If the claim holds, dependency metrics can expose structural side-effects of ATD repayment that quality-focused metrics miss.
  • Repaying ATD may centralize dependencies, meaning short-term fixes can create new maintenance hotspots that need continued attention.
  • ATD files being modified less often suggests debt-affected code is avoided or frozen, potentially hiding structural problems from routine maintenance.
  • Dependency metrics alone are insufficient for ATD impact assessment and should be complemented with other architectural measures.
  • The method, if scaled to more projects, offers a way to compare the long-term architectural consequences of different debt-repayment strategies.

Reading between the lines

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

  • The paper's own Non-ATD control shows a larger average FAN-IN increase (+89.06% vs +57.5%), so the observed centralization may be a general software-evolution effect rather than a consequence of ATD repayment; a matched-pair design on file size and age could separate these explanations.
  • The filter from 116 candidate items to 57 true positives to 18 locatable VioMod items suggests that textual SATD detection captures only a thin slice of architectural debt, implying that structural analysis must be added to NLP-based methods.
  • The negative correlation between cyclomatic complexity and change frequency in ATD files could mean that complex debt-ridden code deters developers from modifying it; if replicated, this would give a concrete mechanism for why architectural debt persists.
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, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper studies the lifecycle of self-admitted architectural technical debt (ATD) by tracing 18 VioMod ATD items from the Li et al. dataset across introduction and repayment, using FAN-IN and FAN-OUT dependency metrics. The authors report that ATD repayment is associated with a 57.5% average FAN-IN increase and a 26.7% FAN-OUT increase, interpreting this as a shift toward dependency centralization and increased architectural complexity, and that ATD files are modified less frequently than Non-ATD files. They also report per-item Mann-Whitney tests, Cliff's delta effect sizes, and partial Spearman correlations with cyclomatic complexity and change counts. The paper provides a replication package and acknowledges in places that the overall effect sizes are negligible.

Significance. If the claims were fully supported, the study would offer a useful empirical account of how ATD repayment alters class-level dependency structure, and its use of a control group and effect sizes would be a methodological strength. The replication package and the worked example are valuable for future studies. However, the headline finding is currently overstated relative to the paper's own numbers: the ATD effect sizes are negligible by the paper's cited thresholds, and the Non-ATD comparison shows larger average increases. The paper's main contribution should be reframed as a small-scale, proof-of-concept demonstration that dependency metrics can trace ATD lifecycles, with a cautionary null result about the specificity and magnitude of connectivity changes.

major comments (4)
  1. [Abstract and Section V-A (Table IV)] The headline claim that 'ATD repayment increased class connectivity, with FAN-IN increasing by 57.5% on average and FAN-OUT by 26.7%, suggesting a shift toward centralization and increased architectural complexity' is not supported by the paper's own statistics. Table IV reports Cliff's delta of 0.1028 for FAN-IN and 0.1213 for FAN-OUT for ATD items, both below the 0.147 threshold that the paper defines as negligible, and the same table shows Non-ATD items with a larger average FAN-IN increase (+89.06%) and a larger effect size (0.2766). The Answer to RQ1 repeats the overstatement. The abstract and RQ1 answer should be revised to report a negligible-to-small, non-ATD-specific shift, unless a direct ATD-versus-Non-ATD comparison of changes is provided that supports a stronger statement.
  2. [Section IV and footnote 6; Table IV] The central comparison is unpaired: the number of ATD-affected files falls from 5,135 at introduction to 3,553 at payment (-44.5%), and the paper explicitly excludes files deleted or merged during repayment from the payment-phase metrics, then applies Mann-Whitney U to the introduction set versus the survivor set. If deleted files have lower FAN-IN, the aggregate distribution and the +57.5% average can change simply because the composition of the two samples differs, even if no surviving file changes its connectivity. The Non-ATD control does not remove this artifact because it also loses 21.26% of files and is likewise unpaired. The paper should report a paired analysis on the intersection of files, or otherwise model the attrition, before attributing the percentage increase to ATD repayment.
  3. [Section V-A] The Mann-Whitney U tests pool 5,135 files from only 18 ATD items (and 753 files from 18 Non-ATD items) and treat every file as an independent observation, although files within one ATD item and one project are correlated. This inflates the reported p-values (e.g., FAN-IN p = 1.24e-16, FAN-OUT p = 5.05e-22) and makes 'statistically significant' uninformative; indeed, Table V shows that for most individual ATD items the null hypothesis is not rejected. Significance claims should be based on item-level summaries, mixed-effects models, or cluster-robust tests, and the text should state clearly that the file-level tests are descriptive rather than evidence of a generalizable effect.
  4. [Section VI and Table VII] The comparison of modification counts between ATD and Non-ATD files does not control for the length of the observation interval: ATD counts span from introduction to repayment, while Non-ATD counts span from the initial commit to the recorded commit, and these intervals need not be comparable. Without normalizing by interval duration, matching intervals, or modeling change rates, the conclusion that 'ATD-related files experience fewer changes' (Answer to RQ2) may simply reflect shorter observation windows for ATD items. The paper should report the interval lengths or use a rate-based analysis.
minor comments (6)
  1. [Section IV and Figure 1] The text states that the median FAN-IN grew from 0.69 to 2.01, but Figure 1 reports medians of 1.0 and 6.5 for the same worked example; please reconcile these values.
  2. [Section IV] The sentence 'the directional test shows that we cannot reject the H1' should be phrased as rejecting the null hypothesis in favor of the alternative; as written it conflates the two hypotheses.
  3. [Section IV] Cliff's delta does not measure the standardized difference between two means; it measures the probability that a randomly selected observation from one group is larger than one from the other. The thresholds are cited correctly, but the definition should be corrected.
  4. [Section III, step 6] There is a typo: 'ommitting' should be 'omitting'.
  5. [Section V-B and Table VI] The table heading 'IT's' should be 'Its', and the legend 'p-value > 0.05' should use 'p-value >= 0.05' or explicitly state the boundary convention for the 'N' category.
  6. [Section III, 'Selection of Violation of modularity ATD'] The filtering from 116 to 18 ATD items is substantial, and 10 of 22 issue-tracker VioMod items could not be linked to a commit hash. The paper should briefly discuss whether unlinked items might differ from linked ones, since this attrition affects the representativeness of the final sample.

Circularity Check

0 steps flagged · score 0.0 of 10

No construction-level circularity: the FAN-IN/FAN-OUT findings are empirical before/after measurements from external tools, not derived from the ATD definition or from fitted parameters.

full rationale

The paper makes no first-principles derivation and fits no model whose output is then called a prediction. RQ1 is answered by comparing FAN-IN and FAN-OUT values measured with the external Understand tool at two git states; RQ2 uses partial Spearman correlations on externally computed metrics. The VioMod definition from Li et al. [23] is used only to filter candidate ATD items, and the reported increase in connectivity is not entailed by that definition, as shown by the paper's own control comparison: Non-ATD items show a larger average FAN-IN increase (+89.06%) than ATD items (+57.5%), and the ATD effect sizes are negligible. The provenance of the ATD labels from Li et al. [10], which shares an author, is a transparency limitation, but the authors independently revalidated the items and the dependent variables come from third-party tools, so no load-bearing argument reduces to a self-citation. The unpaired before/after design caused by deleted files, acknowledged in Section IV ('Excluding those removed files resulted in an unpaired dataset') and in the Section V-A footnote, is a genuine threat to the causal wording in the abstract, but it is a validity/confounding concern, not a circularity: it does not make the measured outcome equivalent to an input by definition. No equation in the paper equates a reported result to the defining criteria of ATD or to a fitted parameter, so no circular step meets the required evidentiary bar.

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

No fitted parameters or invented entities. The study rests on four analytical assumptions: the validity of dependency metrics as ATD proxies, the correctness of the heavily filtered ATD labels, the statistical independence of files within items, and the accuracy of the commit-based lifecycle timing. The first two are acknowledged as threats to validity in the paper; the third is not addressed and materially affects the reported p-values.

assumptions (4)
  • domain assumption FAN-IN and FAN-OUT, as measured by the Understand tool, accurately capture architecturally relevant coupling changes.
    Invoked throughout Sections III-B and VII-C; the construct validity section acknowledges that these metrics may not capture all architectural complexity factors.
  • domain assumption The 18 ATD items that survived filtering (16 analyzable at file level) are valid instances of architecture technical debt.
    Section III 'Selection of Violation of modularity ATD': 116 candidates were reduced by author re-labeling, commit-hash linkage, and duplicate removal, with no external validation of the final set.
  • domain assumption Mann-Whitney U tests treat each affected file as an independent observation, ignoring clustering within ATD items.
    Section V-A pools 5,135 files across ATD items; per-item tests in Table V mostly show no significance, indicating the pooled significance is driven by file-level non-independence.
  • domain assumption The git blame-derived introduction and payment moments represent the true lifecycle of each ATD item.
    Section III step 2: introduction and payment are identified heuristically ('when workarounds were introduced', 'commits that addressed the ATD'), which is subjective and not validated against project documentation.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Tracing the Lifecycle of Architecture Technical Debt in Software Systems: A Dependency Approach." pith.science (2026). https://pith.science/paper/3R6GFXWK

@misc{pith2026250115387,
  author       = {Pith},
  title        = {Pith review of: Tracing the Lifecycle of Architecture Technical Debt in Software Systems: A Dependency Approach},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/3R6GFXWK}},
  note         = {Machine review of arXiv:2501.15387}
}
read the original abstract

Architectural technical debt (ATD) represents trade-offs in software architecture that accelerate initial development but create long-term maintenance challenges. ATD, in particular when self-admitted, impacts the foundational structure of software, making it difficult to detect and resolve. This study investigates the lifecycle of ATD, focusing on how it affects i) the connectivity between classes and ii) the frequency of file modifications. We aim to understand how ATD evolves from introduction to repayment and its implications on software architectures. Our empirical approach was applied to a dataset of SATD items extracted from various software artifacts. We isolated ATD instances, filtered for architectural indicators, and calculated dependencies at different lifecycle stages using FAN-IN and FAN-OUT metrics. Statistical analyses, including the Mann-Whitney U test and Cliff's Delta, were used to assess the significance and effect size of connectivity and dependency changes over time. We observed that ATD repayment increased class connectivity, with FAN-IN increasing by 57.5% on average and FAN-OUT by 26.7%, suggesting a shift toward centralization and increased architectural complexity after repayment. Moreover, ATD files were modified less frequently than Non-ATD files, with changes accumulated in high-dependency portions of the code. Our study shows that resolving ATD improves software quality in the short-term, but can make the architecture more complex by centralizing dependencies. Also, even if dependency metrics (like FAN-IN and FAN-OUT) can help understand the impact of ATD, they should be combined with other measures to capture other effects of ATD on software maintainability.

Figures

Figures reproduced from arXiv: 2501.15387 by the authors.

Figure 1
Figure 1. Data distribution of FAN-IN and FAN-OUT for ATD #1 [PITH_FULL_IMAGE:figures/full_fig_p006_1.png] view at source ↗
Figure 2
Figure 2. Distribution of FAN-IN and FAN-OUT: Introduction vs. Payment Phases of the ATD items [PITH_FULL_IMAGE:figures/full_fig_p007_2.png] view at source ↗
Figure 3
Figure 3. Boxplot of Number of Changes: ATD vs. Non-ATD Files [PITH_FULL_IMAGE:figures/full_fig_p008_3.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Descriptor: C++ Self-Admitted Technical Debt Dataset (CppSATD)

    cs.SE 2025-05 conditional novelty 6.0 of 10

    CppSATD introduces a large C++ comment dataset in which 13,044 comments were confirmed as self-admitted technical debt by human annotators and the remainder were labeled NON-SATD largely by pattern-based inference.

Reference graph

Works this paper leans on

38 extracted references · 36 canonical work pages · cited by 1 Pith paper

  1. [1]

    The wycash portfolio management system,

    W. Cunningham, “The wycash portfolio management system,” ACM Sigplan Oops Messenger , vol. 4, no. 2, pp. 29–30, 1992

    work page 1992

  2. [2]

    Managing technical debt in software engineering (dagstuhl seminar 16162),

    P. Avgeriou, P. Kruchten, I. Ozkaya, and C. Seaman, “Managing technical debt in software engineering (dagstuhl seminar 16162),” in Dagstuhl reports , vol. 6, no. 4. Deutsch: Schloss Dagstuhl-Leibniz- Zentrum fuer Informatik, 2016

    work page 2016

  3. [3]

    An exploratory study on self-admitted technical debt,

    A. Potdar and E. Shihab, “An exploratory study on self-admitted technical debt,” in 2014 IEEE International Conference on Software Maintenance and Evolution . IEEE, 2014, pp. 91–100

    work page 2014

  4. [4]

    Deep Learning and Data Augmentation for Detecting Self-Admitted Technical Debt

    E. Sutoyo, P. Avgeriou, and A. Capiluppi, “Deep learning and data augmentation for detecting self-admitted technical debt,” arXiv preprint arXiv:2410.15804, 2024

    work page Pith review arXiv 2024

  5. [5]

    Using natural language processing to automatically detect self-admitted technical debt,

    E. da Silva Maldonado, E. Shihab, and N. Tsantalis, “Using natural language processing to automatically detect self-admitted technical debt,” IEEE Transactions on Software Engineering , vol. 43, no. 11, pp. 1044–1062, 2017

    work page 2017

  6. [6]

    The lifecycle of technical debt that manifests in both source code and issue trackers,

    J. Tan, D. Feitosa, and P. Avgeriou, “The lifecycle of technical debt that manifests in both source code and issue trackers,” Information and Software Technology, vol. 159, p. 107216, 2023

    work page 2023

  7. [7]

    Impact of architectural technical debt on daily software development work—a survey of software practi- tioners,

    T. Besker, A. Martini, and J. Bosch, “Impact of architectural technical debt on daily software development work—a survey of software practi- tioners,” in 2017 43rd Euromicro Conference on Software Engineering and Advanced Applications (SEAA) . IEEE, 2017, pp. 278–287

    work page 2017

  8. [8]

    A systematic literature review and a unified model of atd,

    ——, “A systematic literature review and a unified model of atd,” in 2016 42th Euromicro Conference on Software Engineering and Advanced Applications (SEAA) . IEEE, 2016, pp. 189–197

    work page 2016

Show all 38 references
  1. [9]

    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

  2. [10]

    Automatic identification of self- admitted technical debt from four different sources,

    Y . Li, M. Soliman, and P. Avgeriou, “Automatic identification of self- admitted technical debt from four different sources,” Empirical Software Engineering, vol. 28, no. 3, pp. 1–38, 2023

    2023

  3. [11]

    Code smells detection via modern code review: A study of the openstack and qt communities,

    X. Han, A. Tahir, P. Liang, S. Counsell, K. Blincoe, B. Li, and Y . Luo, “Code smells detection via modern code review: A study of the openstack and qt communities,” Empirical Software Engineering , vol. 27, no. 6, p. 127, 2022

    2022

  4. [12]

    The danger of architectural technical debt: Contagious debt and vicious circles,

    A. Martini and J. Bosch, “The danger of architectural technical debt: Contagious debt and vicious circles,” in 2015 12th Working IEEE/IFIP Conference on Software Architecture . IEEE, 2015, pp. 1–10

    2015

  5. [13]

    Architectural technical debt: A grounded theory,

    R. Verdecchia, P. Kruchten, and P. Lago, “Architectural technical debt: A grounded theory,” in Software Architecture: 14th European Conference, ECSA 2020, L’Aquila, Italy, September 14–18, 2020, Proceedings 14 . Springer, 2020, pp. 202–219

    2020

  6. [14]

    An overview and comparison of technical debt measurement tools,

    P. C. Avgeriou, D. Taibi, A. Ampatzoglou, F. A. Fontana, T. Besker, A. Chatzigeorgiou, V . Lenarduzzi, A. Martini, A. Moschou, I. Pigazzini et al. , “An overview and comparison of technical debt measurement tools,” Ieee software, vol. 38, no. 3, pp. 61–71, 2020

    2020

  7. [15]

    Development and adoption of satd detec- tion tools: A state-of-practice report,

    E. Sutoyo and A. Capiluppi, “Development and adoption of satd detec- tion tools: A state-of-practice report,” arXiv preprint arXiv:2412.14217, 2024

    2024 arXiv

  8. [16]

    Intercomponent dependency issues in software ecosystems,

    M. Claes, A. Decan, and T. Mens, “Intercomponent dependency issues in software ecosystems,” Software Technology: 10 Years of Innovation in IEEE Computer , pp. 35–57, 2018

    2018

  9. [17]

    Designite: A software design quality assessment tool,

    T. Sharma, P. Mishra, and R. Tiwari, “Designite: A software design quality assessment tool,” in Proceedings of the 1st International Work- shop on Bringing Architectural Design Thinking into Developers’ Daily Activities, 2016, pp. 1–4

    2016

  10. [18]

    Refactoring and its relationship with fan-in and fan-out: An empirical study,

    A. Murgia, R. Tonelli, M. Marchesi, G. Concas, S. Counsell, J. McFall, and S. Swift, “Refactoring and its relationship with fan-in and fan-out: An empirical study,” in 2012 16th European Conference on Software Maintenance and Reengineering . IEEE, 2012, pp. 63–72

    2012

  11. [19]

    An empirical study of fan-in and fan-out in java oss,

    E. Nasseri, S. Counsell, and E. Tempero, “An empirical study of fan-in and fan-out in java oss,” in 2010 Eighth ACIS International Conference on Software Engineering Research, Management and Applications . IEEE, 2010, pp. 36–41

    2010

  12. [20]

    An evolutionary study of fan-in and fan-out metrics in oss,

    A. Mubarak, S. Counsell, and R. M. Hierons, “An evolutionary study of fan-in and fan-out metrics in oss,” in 2010 Fourth International Conference on Research Challenges in Information Science (RCIS) . IEEE, 2010, pp. 473–482

    2010

  13. [21]

    Software complexity and software maintenance: A survey of empirical research,

    C. F. Kemerer, “Software complexity and software maintenance: A survey of empirical research,” Annals of Software Engineering , vol. 1, pp. 1–22, 1995

    1995

  14. [22]

    Towards an ontology of terms on technical debt,

    N. S. Alves, L. F. Ribeiro, V . Caires, T. S. Mendes, and R. O. Spínola, “Towards an ontology of terms on technical debt,” in 2014 sixth international workshop on managing technical debt . IEEE, 2014, pp. 1–7

    2014

  15. [23]

    Identification and remediation of self-admitted technical debt in issue trackers,

    Y . Li, M. Soliman, and P. Avgeriou, “Identification and remediation of self-admitted technical debt in issue trackers,” in 2020 46th Euromicro conference on software engineering and advanced applications (SEAA) . IEEE, 2020, pp. 495–503

    2020

  16. [24]

    Technical debt and system architecture: The impact of coupling on defect-related activity,

    A. MacCormack and D. J. Sturtevant, “Technical debt and system architecture: The impact of coupling on defect-related activity,” Journal of Systems and Software , vol. 120, pp. 170–182, 2016

    2016

  17. [25]

    Design smell detection and analysis for open source java software,

    A. Imran, “Design smell detection and analysis for open source java software,” in 2019 IEEE International Conference on Software Mainte- nance and Evolution (ICSME) . IEEE, 2019, pp. 644–648

    2019

  18. [26]

    Dynamic fan-in and fan- out metrics for program comprehension,

    Y .-y. Wang, Q.-s. Li, P. Chen, and C.-d. Ren, “Dynamic fan-in and fan- out metrics for program comprehension,”Journal of Shanghai University (English Edition), vol. 11, no. 5, pp. 474–479, 2007

    2007

  19. [27]

    Measuring the technical debt,

    U. V ora, “Measuring the technical debt,” in 2022 17th Annual System of Systems Engineering Conference (SOSE) . IEEE, 2022, pp. 185–189

    2022

  20. [28]

    Identifying self-admitted technical debt in issue tracking systems using machine learning,

    Y . Li, M. Soliman, and P. Avgeriou, “Identifying self-admitted technical debt in issue tracking systems using machine learning,” Empirical Software Engineering, vol. 27, no. 6, p. 131, 2022

    2022

  21. [29]

    Understand by scitools,

    Understand, “Understand by scitools,” Scientific Toolworks, Inc, 444 E Tabernacle Suite #B101 St George, UT 84770, 2024, software for scientific tools and analysis. [Online]. Available: http://www.scitools.org

    2024

  22. [30]

    Goal question metric (gqm) approach,

    R. Van Solingen, V . Basili, G. Caldiera, and H. D. Rombach, “Goal question metric (gqm) approach,” Encyclopedia of software engineering, 2002

    2002

  23. [31]

    Spadini, M

    D. Spadini, M. Aniche, and A. Bacchelli, PyDriller: Python Framework for Mining Software Repositories , 2018

    2018

  24. [32]

    The anderson-darling test for normality,

    L. S. Nelson, “The anderson-darling test for normality,” Journal of Quality Technology, vol. 30, no. 3, pp. 298–299, 1998

    1998

  25. [33]

    Mann-whitney u test,

    P. E. McKnight and J. Najab, “Mann-whitney u test,” The Corsini encyclopedia of psychology , pp. 1–1, 2010

    2010

  26. [34]

    Cliff, Ordinal methods for behavioral data analysis

    N. Cliff, Ordinal methods for behavioral data analysis . Psychology Press, 2014

    2014

  27. [35]

    New York, NY: Springer New York, 2008, pp

    Spearman Rank Correlation Coefficient . New York, NY: Springer New York, 2008, pp. 502–505. [Online]. Available: https://doi.org/10. 1007/978-0-387-32833-1_379

    2008

  28. [36]

    What types of defects are really dis- covered in code reviews?

    M. V . Mäntylä and C. Lassenius, “What types of defects are really dis- covered in code reviews?” IEEE Transactions on Software Engineering, vol. 35, no. 3, pp. 430–448, 2008

    2008

  29. [37]

    How and why we end up with complex methods: a multi-language study,

    M. Lopes and A. Hora, “How and why we end up with complex methods: a multi-language study,” Empirical Software Engineering , vol. 27, no. 5, p. 115, 2022

    2022

  30. [38]

    Technical debt in the peer- review documentation of r packages: A ropensci case study,

    Z. Codabux, M. Vidoni, and F. H. Fard, “Technical debt in the peer- review documentation of r packages: A ropensci case study,” in 2021 IEEE/ACM 18th International Conference on Mining Software Reposi- tories (MSR). IEEE, 2021, pp. 195–206

    2021

Pith tools

Reviewed August 10, 2026 · model on record in the stance chip above.