Pith. sign in

REVIEW 5 major objections 5 minor 48 references

Code Improvement Practices at Meta

T0 review · 5 major / 5 minor · reviewed 2026-08-16 · deepseek-v4-flash

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

Pith's one-line read At Meta, over 14% of code changes are explicitly devoted to code improvement, and reengineering measurably cuts authoring time and outage incidence.

desk verdict Descriptive account of Meta's code-improvement practices is genuinely new; the pre/post impact claims are too uncontrolled to support the abstract's causal wording. read the letter →

arxiv 2504.12517 v2 pith:DASZ44I7 submitted 2025-04-16 cs.SE

Audris Mockus , Peter C Rigby , Rui Abreu , Anatoly Akkerman , Yogesh Bhootada , Payal Bhuptani , Gurnit Ghardhora , Lan Hoang Dao
show 15 more authors
Chris Hawley Renzhi He Sagar Krishnamoorthy Sergei Krauze Jianmin Li Anton Lunov Dragos Martac Francois Morin Neil Mitchell Venus Montes Maher Saba Matt Steiner Andrea Valori Shanchao Wang Nachiappan Nagappan
This is my paper · ORCID
classification cs.SE
keywords codeimprovementrefactoringtechnicaldebtdeadremovalDiffAuthoringTimesoftwaresupplychaincentralityBetterEngineering
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 aims to show how a large company that ships software rapidly keeps its codebase maintainable by treating code improvement as a continuous, partially structured practice. It reports that at Meta more than 14% of code changes are explicitly devoted to perfective maintenance, a share far above the roughly 4% reported in earlier industry work. It claims that reengineering targeted at dead code, cyclomatic complexity, large classes, and platformization produces measurable gains: authoring time falls, outage-triggering changes fall, and code complexity drops. It also proposes a set of prioritization criteria, centered on a software supply chain network and Katz centrality, for choosing which code to reengineer. A sympathetic reader should take the paper as evidence that deliberate, tool-supported code improvement can coexist with rapid release cycles.

What carries the argument

The load-bearing machinery is a keyword-based diff classifier plus a before-and-after matched-file comparison using the software supply chain network. The keyword classifier tags diffs whose titles or tags contain terms like "remove", "delete", "cleanup", "refactor", "dead", or "better engineering", and yields the 14.2% share. The impact evaluation identifies reengineering diffs through task links, tracks all files they touch, and compares pre- and post-intervention periods for outage incidence, Diff Authoring Time (the time from first edit session to landing the diff), session count, cyclomatic complexity, and Katz centrality on a combined network of call graphs, co-changes, and author-to-file links. Control files are matched by size, language, and pre-intervention centrality so that adjusted centrality changes can be separated from global graph drift. The named identity at the center is Katz centrality, which scores a file by the importance of its neighbors rather than by degree alone.

What would settle it

Take a random sample of diffs at Meta that carry none of the improvement keywords and have engineers label them as perfective or not; if many are perfective despite lacking the keywords, the 14.2% share is a lower bound that could be much higher, while finding that most keyword-tagged diffs are actually feature work would deflate it. A sharper test would apply the same keyword methodology to a codebase where refactoring commits are recorded in a structured field and check whether the classifier recovers that known number.

Watch

Extended reading notes

Core claim

The central discovery is that code improvement at Meta is neither rare nor purely top-down: it is an ecology of organic diff-level cleanup, gamified Better Engineering engagement, and dedicated strategic initiatives, and it accounts for 14.2% of all diffs when identified through title and tag keywords. When a suborganization's six-month reengineering effort is evaluated by comparing files and diffs before and after, dead code removal and CCN-driven decompositions show 90% and 55% reductions in SEV-triggering diffs; median Diff Authoring Time drops by 41% to 77% across the four task types; editing sessions fall by 19% to 67%; cyclomatic complexity decreases by up to 26% for CCN-driven work; and, contrary to expectation, call-graph centrality increases. The authors interpret the centrality increase as an open question, possibly an artifact of co-change and author-to-file relationships that lag the intervention or of large-class splits creating more files. The paper claims this as a replication and extension of prior reengineering impact studies, with the new finding that a much larger fraction of changes is perfective than earlier estimates suggested.

Load-bearing premise

The paper's headline share of 14.2% rests on the assumption that diffs whose title or tags contain words like "remove", "delete", "cleanup", "refactor", "dead", or "better engineering" accurately capture all, and only, perfective maintenance.

Editorial extensions

If this is right

  • A company can spend over 14% of its change traffic on perfective maintenance without sacrificing release cadence.
  • Dead code removal and complexity-driven decompositions are the forms of reengineering most clearly associated with quality gains, with 90% and 55% reductions in the proportion of outage-triggering diffs.
  • Reengineering shortens authoring time for the touched files by 41% to 77%, which supports treating Diff Authoring Time as a primary return-on-investment metric for improvement work.
  • Prioritization should target actively changed, high-centrality, high-effort files rather than peripheral smelly code, because the expected benefit scales with future change frequency.
  • Call-graph centrality should not be assumed to decrease after reengineering; the paper's observed increases signal either measurement lag or a structural side effect of splitting large classes.

Reading between the lines

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

  • If the 14.2% share is confirmed by manual inspection, it would imply that organic, developer-initiated improvement is a larger quality force than structured refactoring programs in large tech companies, since Better Engineering-tagged diffs account for only 4.3% of the total.
  • The centrality increase could be tested directly by recomputing adjusted centrality with a longer post-period, such as 12 months, to see whether co-change and authorship networks converge back down after the reengineering settles.
  • The prioritization criteria, especially normalized Diff Authoring Time and knowledge-loss share, could be packaged as a general tool for other companies: rank files by future-facing change load rather than by current smell counts, which is the paper's implicit design principle.
  • A cross-company replication using the same keyword classifier could settle whether the 14% versus 4% gap is a Meta-specific artifact or a sign that earlier estimates are outdated.
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

5 major / 5 minor

Summary. The paper presents a mixed-methods case study at Meta investigating how a large company counteracts code decay: it catalogues code improvement practices (RQ1), develops prioritization criteria (RQ2), finds organic or 'grass-roots' perfective maintenance (RQ3), and evaluates the impact of reengineering on outages, authoring time, sessions, complexity, and call-graph centrality (RQ4). The authors report that over 14% of diffs are explicitly devoted to code improvement, and that reengineering leads to substantial reductions in outage incidence, DAT (23%–59%), sessions, and complexity, whereas centrality unexpectedly increases. The study combines action research, analysis of internal documents, and an observational before/after analysis of 1,000+ reengineered files.

Significance. If the quantitative claims held, the paper would be one of the few industrial-scale evaluations of code reengineering, with rare insider access to Meta's practices and metrics. Its contributions include a novel catalog of practices (Better Engineering, gamification, badges), a set of operationalized prioritization metrics (Table II), and a replication attempt of earlier reengineering studies [6]–[8]. The paper honestly reports a rejected hypothesis (H4: centrality did not decrease), which is a strength. However, the proprietary data are not released, and the key causal claims rest on observational before/after comparisons without control groups for most outcomes. The significance of the work is therefore conditional on addressing the methodological gaps below.

major comments (5)
  1. [Section VII.A, Tables VI–IX] The pre/post comparisons for H1 (outages), H2 (DAT), H3 (sessions), and H5 (complexity) have no comparison group. Because Section VI describes prioritization criteria that explicitly select files with high DAT, prior outages, and high complexity, the treated files are selected on the outcome variables. The observed improvements could stem from regression to the mean, company-wide trends, or the mapping of old filenames to current names, which changes the composition of the analyzed file set. The matched-control approach used for H4 should be applied to the other outcomes, and the analysis should report the numbers of files and diffs in each period. Without this, the conclusion of 'substantial improvements in quality and speed' is not supported.
  2. [Section VII.C, Table VI] The reported odds ratios are not reproducible from the displayed proportions. For dead code removal, the text states OR=5.2 and a '90% decrease,' but the SEV proportions (before 76%, after 24%) imply an odds ratio of about 0.1 (a 90% decrease in odds) if interpreted as column percentages, while the no-SEV proportions (57%/43%) imply a different ratio if interpreted as row percentages; no combination of the four displayed numbers yields OR=5.2. An OR of 5.2 would correspond to an 81% decrease in odds (1 – 1/5.2). The same issue applies to the CCN row (OR=1.55 vs '55% decrease'). Please provide the raw 2x2 contingency tables and clarify the direction of the odds ratio.
  3. [Section V.A, Table I] The claim that 14.2% of diffs are 'explicitly devoted to code improvement' rests entirely on a keyword heuristic applied to diff titles/tags. The paper reports that 'at least 20 diffs' per keyword were sampled and then 'refined to exclude occasional enhancements,' but no precision, recall, or inter-rater agreement is reported. Without a validation against a reference set of manually classified diffs, the headline figure may over- or under-count perfective maintenance, and the comparison to the prior 4% (from Mockus and Votta [26]) is not credible. At minimum, report the number of sampled diffs, the true/false positive counts per keyword, and a sensitivity analysis with stricter and looser keyword sets.
  4. [Tables VII–X] The effect sizes are reported as point estimates without confidence intervals or raw counts. For example, Table VII reports median DAT changes from 0.23 to 0.59 with only a note that a Mann-Whitney test was used; Table IX reports average complexity decreases without a CI. Given the high variance of DAT and complexity metrics, the reader cannot judge the precision of these estimates. Please report 95% confidence intervals (or bootstrap CIs) for each effect size and the number of diffs/files contributing to each comparison.
  5. [Section IX.C] The internal-validity section does not address the selection-confounding and population-change threats identified above, and it does not account for multiple testing across four task types and five hypotheses. With significance tests run for four task types on each of five outcomes, some significant results are expected by chance; the paper should either apply a correction or explicitly report all tests performed, including non-significant ones.
minor comments (5)
  1. [Section IX.B] The sentence 'Organic reengineering effort, on the other hand, might be undertaken as part of regular coding activities and might include' ends mid-sentence with no continuation; it should be completed or revised.
  2. [Abstract] Grammatical error: 'Our investigation to prioritize... lead to the development' should be 'led to the development.'
  3. [Table VI] The column headers 'Proportion of Diffs (no Sev) during the period' and 'Proportion of SEV-triggering Diffs' are ambiguous; clarify whether the proportions are computed within a period or across periods, and state the denominator for each percentage.
  4. [Section VII.A] The description of how 'current filename' mapping handles renamed files is difficult to follow; a small illustrative example of the mapping and its effect on the pre/post file sets would improve clarity.
  5. [Figure 1] The caption notes that internal badges are replaced with GitHub analogues; please also state explicitly that actual badge images are omitted for confidentiality, so readers understand the figure is illustrative rather than literal.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper reports measurements of internal task and diff data; no fitted parameter is renamed as a prediction and no load-bearing result rests on a self-citation chain.

full rationale

The paper's central claims are empirical measurements rather than derivations, and none of the reported quantities are defined in terms of a fitted parameter. The 14.2% code-improvement share is the result of a keyword-based search over diff tags and titles; the keyword list is an operationalization choice, not a constant fitted to make the share come out to a target value. The impact analysis compares pre- and post-reengineering outcomes for files touched by reengineering diffs, with a matched control group for the centrality hypothesis; these are direct observations of outcome variables, not predictions generated from a model whose inputs include those same outcomes. The comparison with prior work, including the authors' own earlier study [6], is a disclosed replication and the conclusions are not formally entailed by that citation. The internal inconsistency in Table VI and the absence of control groups for several hypotheses are validity and reporting concerns, not circularity, because they do not make any claimed result true by construction. The paper is therefore self-contained with respect to circularity reasoning.

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

The analysis is observational and uses internal Meta telemetry. No new formal or physical entities are introduced. The main assumptions are operational: that keyword tags, task-diff links, and DAT faithfully reflect developer intent and effort. No free parameters are fitted; all reported numbers are summary statistics of proprietary internal data.

assumptions (4)
  • domain assumption Meta's task tracking system accurately links diffs to tasks and is routinely used for effort evaluation.
    Section VII-A states that links between tasks and changes are carefully tracked and used to evaluate their impact; if links are incomplete, the identification of reengineering diffs is biased.
  • domain assumption Keyword and tag search (cleanup, remove, delete, refactoring, better engineering, dead, etc.) is a valid operationalization of perfective maintenance intent.
    Section V and Table I; the entire 14.2% estimate and the comparison to prior 4% rest on this heuristic classification.
  • domain assumption Diff Authoring Time (DAT) accurately measures time spent authoring and landing a diff.
    Table IV and Section VII-A define and rely on DAT as the primary productivity outcome; if DAT is affected by unrelated activity such as meetings or context switching, the reported reductions are compromised.
  • domain assumption Matched control files provide a valid counterfactual for centrality changes.
    Section VII-A uses case matching on size, language, and pre-period centrality; the adjusted centrality comparison (Table X) assumes this matching removes confounding.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Code Improvement Practices at Meta." pith.science (2026). https://pith.science/paper/DASZ44I7

@misc{pith2026250412517,
  author       = {Pith},
  title        = {Pith review of: Code Improvement Practices at Meta},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/DASZ44I7}},
  note         = {Machine review of arXiv:2504.12517}
}
read the original abstract

The focus on rapid software delivery inevitably results in the accumulation of technical debt, which, in turn, affects quality and slows future development. Yet, companies with a long history of rapid delivery exist. Our primary aim is to discover how such companies manage to keep their codebases maintainable. Method: we investigate Meta's practices by collaborating with engineers on code quality and by analyzing rich source code change history to reveal a range of practices used for continual improvement of the codebase. In addition, we replicate several aspects of previous industry cases studies investigating the impact of code reengineering. Results: Code improvements at Meta range from completely organic grass-roots done at the initiative of individual engineers, to regularly blocked time and engagement via gamification of Better Engineering (BE) work, to major explicit initiatives aimed at reengineering the complex parts of the codebase or deleting accumulations of dead code. Over 14% of changes are explicitly devoted to code improvement and the developers are given ``badges'' to acknowledge the type of work and the amount of effort. Our investigation to prioritize which parts of the codebase to improve lead to the development of metrics to guide this decision making. Our analysis of the impact of reengineering activities revealed substantial improvements in quality and speed as well as a reduction in code complexity. Overall, such continual improvement is an effective way to develop software with rapid releases, while maintaining high quality.

Figures

Figures reproduced from arXiv: 2504.12517 by the authors.

Figure 1
Figure 1. An engineer’s profile may reach 70 or more badges. The images of [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

48 extracted references · 41 canonical work pages

  1. [6]

    Refactoring for changeability: A way to go?

    B. Geppert, A. Mockus, and F. Robler, “Refactoring for changeability: A way to go?” in 11th IEEE International Software Metrics Symposium (METRICS’05). IEEE, 2005, pp. 10–pp

    work page 2005

  2. [8]

    A field study of refactoring challenges and benefits,

    M. Kim, T. Zimmermann, and N. Nagappan, “A field study of refactoring challenges and benefits,” in Proceedings of the ACM SIGSOFT 20th International Symposium on the Foundations of Software Engineering , 2012, pp. 1–11

    work page 2012

  3. [26]

    Identifying reasons for software changes using historic databases,

    Mockus and V otta, “Identifying reasons for software changes using historic databases,” in Proceedings 2000 international conference on software maintenance. IEEE, 2000, pp. 120–130

    work page 2000

  4. [1]

    Does code decay? assessing the evidence from change management data,

    S. G. Eick, T. L. Graves, A. F. Karr, J. S. Marron, and A. Mockus, “Does code decay? assessing the evidence from change management data,” IEEE transactions on software engineering , vol. 27, no. 1, pp. 1–12, 2001

    work page 2001

  5. [2]

    An exploration of technical debt,

    E. Tom, A. Aurum, and R. Vidgen, “An exploration of technical debt,” Journal of Systems and Software , vol. 86, no. 6, pp. 1498–1516, 2013

    2013

  6. [3]

    Formulation and preliminary test of an empirical theory of coordination in software engineering,

    J. Herbsleb and A. Mockus, “Formulation and preliminary test of an empirical theory of coordination in software engineering,” in 2003 International Conference on Foundations of Software Engineering . Helsinki, Finland: ACM Press, October 2003. [Online]. Available: http://dl.acm.org/authorize?787510

    work page 2003

  7. [4]

    Continuous software engineering and beyond: trends and challenges,

    B. Fitzgerald and K.-J. Stol, “Continuous software engineering and beyond: trends and challenges,” in Proceedings of the 1st International Workshop on rapid continuous software engineering , 2014, pp. 1–9

    2014

  8. [5]

    Taplin, Move fast and break things: How Facebook, Google, and Amazon have cornered culture and what it means for all of us

    J. Taplin, Move fast and break things: How Facebook, Google, and Amazon have cornered culture and what it means for all of us . Pan Macmillan, 2017

    work page 2017

Show all 48 references
  1. [7]

    A case study on the impact of refactoring on quality and productivity in an agile team,

    R. Moser, P. Abrahamsson, W. Pedrycz, A. Sillitti, and G. Succi, “A case study on the impact of refactoring on quality and productivity in an agile team,” in IFIP Central and East European Conference on Software Engineering Techniques. Springer, 2007, pp. 252–266

    2007

  2. [9]

    Quantifying and mitigating turnover-induced knowledge loss: case studies of chrome and a project at avaya,

    P. C. Rigby, Y . C. Zhu, S. M. Donadelli, and A. Mockus, “Quantifying and mitigating turnover-induced knowledge loss: case studies of chrome and a project at avaya,” in Proceedings of the 38th International Conference on Software Engineering , 2016, pp. 1006–1016

    2016

  3. [10]

    Fowler, Refactoring

    M. Fowler, Refactoring. Addison-Wesley Professional, 2018

    2018

  4. [11]

    When does a refactoring induce bugs? an empirical study,

    G. Bavota, B. De Carluccio, A. De Lucia, M. Di Penta, R. Oliveto, and O. Strollo, “When does a refactoring induce bugs? an empirical study,” in 2012 IEEE 12th International Working Conference on Source Code Analysis and Manipulation . IEEE, 2012, pp. 104–113

    2012

  5. [12]

    Empirical evaluation of the impact of object- oriented code refactoring on quality attributes: A systematic literature review,

    J. Al Dallal and A. Abdin, “Empirical evaluation of the impact of object- oriented code refactoring on quality attributes: A systematic literature review,” IEEE Transactions on Software Engineering , vol. 44, no. 1, pp. 44–69, 2017

    2017

  6. [13]

    Quantifying the effect of code smells on maintenance effort,

    D. I. Sjøberg, A. Yamashita, B. C. Anda, A. Mockus, and T. Dyb ˚a, “Quantifying the effect of code smells on maintenance effort,” IEEE Transactions on Software Engineering , vol. 39, no. 8, pp. 1144–1156, 2012

    2012

  7. [14]

    Why we refactor? confessions of github contributors,

    D. Silva, N. Tsantalis, and M. T. Valente, “Why we refactor? confessions of github contributors,” in Proceedings of the 2016 24th acm sigsoft international symposium on foundations of software engineering , 2016, pp. 858–870

    2016

  8. [15]

    Why developers refactor source code: A mining-based study,

    J. Pantiuchina, F. Zampetti, S. Scalabrino, V . Piantadosi, R. Oliveto, G. Bavota, and M. D. Penta, “Why developers refactor source code: A mining-based study,” ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 29, no. 4, pp. 1–30, 2020

    2020

  9. [16]

    Six strategies for generalizing software engineering theories,

    R. Wieringa and M. Daneva, “Six strategies for generalizing software engineering theories,” Science of computer programming , vol. 101, pp. 136–152, 2015

    2015

  10. [17]

    On the reproducibility of empirical software engineering studies based on data retrieved from development repositories,

    J. M. Gonz ´alez-Barahona and G. Robles, “On the reproducibility of empirical software engineering studies based on data retrieved from development repositories,” Empirical Software Engineering , vol. 17, pp. 75–89, 2012

    2012

  11. [18]

    Experiences from replicating a case study to investigate reproducibility of software development,

    A. Mockus, B. Anda, and D. I. Sjøberg, “Experiences from replicating a case study to investigate reproducibility of software development,” in Proceedings of the 1st International Workshop on Replication in Empirical Software Engineering Research , 2010

    2010

  12. [19]

    Repro- ducibility and credibility in empirical software engineering: A case study based on a systematic literature review of the use of the szz algorithm,

    G. Rodr ´ıguez-P´erez, G. Robles, and J. M. Gonz ´alez-Barahona, “Repro- ducibility and credibility in empirical software engineering: A case study based on a systematic literature review of the use of the szz algorithm,” Information and Software Technology , vol. 99, pp. 164–...

    2018

  13. [20]

    Dead code removal at meta: Automatically deleting millions of lines of code and petabytes of deprecated data,

    W. Shackleton, K. Cohn-Gordon, P. C. Rigby, R. Abreu, J. Gill, N. Nagappan, K. Nakad, I. Papagiannis, L. Petre, G. Megreli et al. , “Dead code removal at meta: Automatically deleting millions of lines of code and petabytes of deprecated data,” in Proceedings of the 31st ACM Jo...

    2023

  14. [21]

    Assessing the state of software in a large enterprise,

    R. L. Hackbarth, A. Mockus, J. D. Palframan, and D. M. Weiss, “Assessing the state of software in a large enterprise,” Empirical Software Engineering, vol. 15, pp. 219–249, 2010

    2010

  15. [22]

    Beliefs, practices, and personalities of software engineers: a survey in a large software company,

    E. K. Smith, C. Bird, and T. Zimmermann, “Beliefs, practices, and personalities of software engineers: a survey in a large software company,” in Proceedings of the 9th International Workshop on Cooperative and Human Aspects of Software Engineering , 2016, pp. 15–18

    2016

  16. [23]

    Leffingwell, Scaling software agility: best practices for large enterprises

    D. Leffingwell, Scaling software agility: best practices for large enterprises. Pearson Education, 2007

    2007

  17. [24]

    Prioritization of classes for refac- toring: A step towards improvement in software quality,

    R. Malhotra, A. Chug, and P. Khosla, “Prioritization of classes for refac- toring: A step towards improvement in software quality,” in Proceedings of the Third International Symposium on Women in Computing and Informatics, 2015, pp. 228–234

    2015

  18. [25]

    The dimensions of maintenance,

    E. B. Swanson, “The dimensions of maintenance,” in Proceedings of the 2nd international conference on Software engineering , 1976, pp. 492–497

    1976

  19. [27]

    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

    2014

  20. [28]

    Does gamification work?–a literature review of empirical studies on gamification,

    J. Hamari, J. Koivisto, and H. Sarsa, “Does gamification work?–a literature review of empirical studies on gamification,” in 2014 47th Hawaii international conference on system sciences . Ieee, 2014, pp. 3025–3034

    2014

  21. [29]

    Gamification in theory and action: A survey,

    K. Seaborn and D. I. Fels, “Gamification in theory and action: A survey,” International Journal of human-computer studies , vol. 74, pp. 14–31, 2015

    2015

  22. [30]

    Lupton, The quantified self

    D. Lupton, The quantified self . John Wiley & Sons, 2016

    2016

  23. [31]

    Modeling the centrality of developer output with software supply chains,

    A. Mockus, P. C. Rigby, R. Abreu, P. Suresh, Y . Chen, and N. Nagappan, “Modeling the centrality of developer output with software supply chains,” in Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Enginee...

    2023

  24. [32]

    Measuring productivity impact with diff authoring time,

    “Measuring productivity impact with diff authoring time,” https://engineering.fb.com/2025/01/16/developer-tools/ measuring-productivity-impact-with-diff-authoring-time/, January 2024, episode 69, Meta Tech Podcast

    2025

  25. [33]

    Developer fluency: Achieving true mastery in software projects,

    M. Zhou and A. Mockus, “Developer fluency: Achieving true mastery in software projects,” in Proceedings of the eighteenth ACM SIGSOFT international symposium on Foundations of software engineering , 2010, pp. 137–146

    2010

  26. [34]

    A new status index derived from sociometric analysis,

    L. Katz, “A new status index derived from sociometric analysis,” Psychometrika, vol. 18, no. 1, pp. 39–43, 1953

    1953

  27. [35]

    A complexity measure,

    T. McCabe, “A complexity measure,” IEEE Transactions on Software Engineering, vol. SE-2, no. 4, pp. 308–320, 1976

    1976

  28. [36]

    Matching methods for causal inference: A review and a look forward,

    E. A. Stuart, “Matching methods for causal inference: A review and a look forward,” Statistical science: a review journal of the Institute of Mathematical Statistics, vol. 25, no. 1, p. 1, 2010

    2010

  29. [37]

    Software developers’ perceptions of productivity,

    A. N. Meyer, T. Fritz, G. C. Murphy, and T. Zimmermann, “Software developers’ perceptions of productivity,” in Proceedings of the 22nd ACM SIGSOFT International Symposium on Foundations of Software Engineering, 2014, pp. 19–29

    2014

  30. [38]

    Putting it all together: Using socio-technical networks to predict failures,

    C. Bird, N. Nagappan, H. Gall, B. Murphy, and P. Devanbu, “Putting it all together: Using socio-technical networks to predict failures,” in 2009 20th International Symposium on Software Reliability Engineering . IEEE, 2009, pp. 109–119

    2009

  31. [39]

    Predicting defects using network analysis on dependency graphs,

    T. Zimmermann and N. Nagappan, “Predicting defects using network analysis on dependency graphs,” in Proceedings of the 30th international conference on Software engineering , 2008, pp. 531–540

    2008

  32. [40]

    Categorizing bugs with social networks: a case study on four open source software communities,

    M. S. Zanetti, I. Scholtes, C. J. Tessone, and F. Schweitzer, “Categorizing bugs with social networks: a case study on four open source software communities,” in 2013 35th International Conference on Software Engineering (ICSE). IEEE, 2013, pp. 1032–1041

    2013

  33. [41]

    The small-world effect: The influence of macro-level properties of developer collaboration networks on open-source project success,

    P. V . Singh, “The small-world effect: The influence of macro-level properties of developer collaboration networks on open-source project success,” ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 20, no. 2, pp. 1–27, 2010

    2010

  34. [42]

    Using social network analysis for mining collaboration data in a defect tracking system for risk and vulnerability analysis,

    A. Sureka, A. Goyal, and A. Rastogi, “Using social network analysis for mining collaboration data in a defect tracking system for risk and vulnerability analysis,” in Proceedings of the 4th india software engineering conference, 2011, pp. 195–204

    2011

  35. [43]

    Characterizing and understanding software developer networks in security development,

    S. Wang and N. Nagappan, “Characterizing and understanding software developer networks in security development,” in 2021 IEEE 32nd International Symposium on Software Reliability Engineering (ISSRE) . IEEE, 2021, pp. 534–545

    2021

  36. [44]

    Boehm, Software Engineering Economics

    B. Boehm, Software Engineering Economics . Prentice-Hall, 1981

    1981

  37. [45]

    Missing data in software engineering,

    A. Mockus, “Missing data in software engineering,” in Guide to Advanced Empirical Software Engineering , J. S. et al., Ed. Springer-Verlag, 2008, pp. 185–200. [Online]. Available: papers/missing.pdf

    2008

  38. [46]

    Software support tools and experimental work,

    ——, “Software support tools and experimental work,” in Empirical Software Engineering Issues: Critical Assessments and Future Directions , V . Basili and et al, Eds. Springer, 2007, vol. LNCS 4336, pp. 91–99. [Online]. Available: papers/SSTaEW.pdf

    2007

  39. [47]

    Organizational volatility and its effects on software defects,

    ——, “Organizational volatility and its effects on software defects,” in ACM SIGSOFT / FSE , Santa Fe, New Mexico, November 7–11 2010, pp. 117–126. [Online]. Available: http://dl.acm.org/authorize?309271

    2010

  40. [48]

    Engineering big data solutions,

    ——, “Engineering big data solutions,” in ICSE’14 FOSE , 2014. [Online]. Available: https://dl.acm.org/authorize?N14216

    2014

Pith tools

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