{"id":"2acc9607-b1bd-444f-8f15-3f9b209bbeb2","arxiv_id":"2501.13520","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":2,"one_line_summary":"Centrality metrics calculated on service dependency graphs are only weakly to moderately correlated with traditional size, complexity, and quality metrics across 53 microservices, suggesting they capture a distinct architectural perspective.","lead":"Analyzing 53 microservices from 13 open-source Java projects, the authors computed network centrality and traditional software metrics and tested whether the two families of measures are related. They find mostly weak to moderate correlations, and argue that centrality offers a fresh angle for spotting architectural anti-patterns like Hub, Nano, and Mega services.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Code2DFD false negatives may correlate with service size/complexity, biasing the centrality–SM correlations that ground the paper's central claim.","rationale":"Both the reader and I identify graph reconstruction error as the critical vulnerability. The central claim is an empirical statement about correlations between centrality and software metrics; any systematic measurement error in the graph directly threatens that statement. I do not see an internal inconsistency in the paper's logic; rather, the assumption of unbiased FNs is unverified. The proposed test would settle whether the assumption holds. If it fails, the main conclusion could be an artifact. Since this is an addressable methodological gap rather than a demonstrated fatal flaw, the current CONDITIONAL verdict is appropriate.","tokens_in":17232,"tokens_out":5713,"duration_ms":52218,"concrete_test":"Select a stratified sample of 10 microservices from the retained 24 projects (covering high and low size/complexity). Manually reconstruct their ground-truth call graphs by static reading of the source (tracking RestTemplate, FeignClient, WebClient, @Autowired, and messaging calls). Compute the missed-edge rate between Code2DFD's graph and the ground-truth graph for each service, and test Spearman correlation between this missed-edge rate and the service's Understand TLOC/CountLineCodeExe and Jasome WMC/VG. If missed-edge rate correlates significantly (p<0.05) with size or complexity, then the centrality–SM correlations reported in Figures 3 and 5 are confounded by FN bias.","verdict_should_be":"UNCHANGED","load_bearing_attack":"Section IV-C1 reports that Code2DFD's connection recovery has false negatives (FNs): 88 of 112 projects were excluded because recovered edges were too few relative to components, and even the retained 24 projects are pre-processed by dropping disconnected nodes and single-connection databases. The paper assumes the remaining FNs are unsystematic with respect to software metrics. This is load-bearing because centrality is computed on these reconstructed graphs. If the FN rate is higher for services with many classes, long call chains, or complex Spring wiring, then degree, betweenness, and closeness scores are underestimated for exactly those services that score high on size/complexity metrics. That would produce spurious negative correlations of the kind reported in RQ1/RQ2 (centrality vs. CountLineCodeExe, CountLineComment, WMC, cognitive complexity) or suppress positive correlations, undercutting the Section VIII conclusion that CMs are 'weak to moderately correlated, when statistically significant' except for construction effects. The paper's threats-to-validity section acknowledges FNs but does not test whether FN severity is associated with the SMs used in the correlations. Without that test, the central empirical claim is not securely established.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"This paper investigates whether network centrality metrics computed on service dependency graphs (SDGs) provide information about microservice architecture that is not already captured by traditional software metrics (size, complexity, quality). The authors reconstruct SDGs for 24 open-source Java Spring projects using the Code2DFD tool, compute 11 centrality scores for 53 microservices, collect 155 software metrics using Understand, Jasome, and SonarQube, and test Spearman correlations between centrality and software metrics. They report 282 statistically significant correlations out of 902 at alpha=0.01, mostly weak to moderate, and conclude that centrality offers a complementary perspective, with ratio-based centralities promising for anti-pattern detection and subgraph centrality requiring further study. A replication package is provided.","tokens_in":17359,"tokens_out":6514,"duration_ms":57092,"significance":"Should the central claim survive scrutiny, the contribution is useful: it is one of the first empirical mappings between microservice centrality and standard static metrics, and it offers a concrete practical proposal (ratio-based centralities for hub/nano/mega detection). The study merges four existing datasets, uses multiple industrial-strength static analysis tools, reports a detailed project triage with explicit exclusion counts, and releases raw data, scripts, and reconstructed SDGs in a replication package. The main limitations are also honestly acknowledged in the threats-to-validity section, although, as detailed below, some of those acknowledged threats are not adequately addressed.","major_comments":[{"comment":"The central empirical result rests on the untested assumption that Code2DFD's false-negative connection errors are not systematically related to the software metrics studied. After excluding 88 of 112 projects, the retained 24 SDGs are additionally pre-processed by removing disconnected components and single-connection databases. If the false-negative rate is higher for services with many classes, long call chains, or complex Spring wiring, then degree, betweenness, and closeness are underestimated exactly for services that score high on size or complexity metrics, which would spuriously create or suppress correlations of the kind reported in RQ1 and RQ2. Section VII acknowledges false negatives but does not test whether reconstruction quality is associated with any software metric. Please add a sensitivity analysis, e.g., comparing Code2DFD output against the manually reconstructed DFDs in the microSecEnD dataset (used in Section III), or correlating edge/component ratios and the proportion of removed nodes with the studied SMs. Without such a test, the Section VIII conclusion that CMs are only weakly to moderately correlated with SMs is not securely established.","section":"§IV-C1, §VII"},{"comment":"The paper's own interpretation in Section VI states that the significant correlations arise 'by construction of the problem,' yet the analysis does not separate construction-driven from genuinely informative correlations. Degree centrality is computed on edges that Code2DFD extracts from public API calls, and the size metrics NPM/PMd/CountDeclMethodPublic count the same public methods; likewise Fin/Fout/Si count method calls, so their strong positive correlations with degree centrality (reported in Section V-B) are at least partly definitional. The conclusion in Section VIII that CMs are 'weak to moderately correlated, when statistically significant, with traditional SMs, except when the correlations arise from the SDG's structural properties' is therefore close to a restatement of the method rather than an empirical finding. Please report the correlation results separately for the subset of metrics that are not definitionally tied to SDG edge extraction, and quantify how many of the 282 significant correlations remain after excluding that subset. Also reconcile the 'weak to moderate' summary with the 'strongly positively correlated' wording used for Fin/Fout/Si.","section":"§V-B, §VI, §VIII"},{"comment":"The 53 microservices are not independent observations: they are nested in only 13 systems, and centrality scores within one system are inter-dependent by construction (e.g., degree scores sum to the total edge count of that system's SDG). Spearman's rho and its p-values as computed in the paper assume independence, so the reported significance levels are likely inflated and the correlation estimates may be dominated by between-system differences rather than within-system relationships between centrality and software metrics. Please account for the nesting (e.g., with mixed-effects models, cluster-robust p-values, or separate per-system analyses) or justify why the dependence does not affect the conclusions.","section":"§IV-D"},{"comment":"The multiple-testing control is insufficient for the claim based on 902 correlations. At alpha=0.01, roughly 9 false positives are expected; while the reported 282 significant correlations far exceed this number, the paper does not control the false discovery rate and does not report confidence intervals for the rho values. Given that many of the 155 metrics are aggregated variants of the same underlying counts (sum/avg/max), a Benjamini-Hochberg adjustment or a table of effect sizes with confidence intervals would strengthen the quantitative support for the '282 cases' result. This is a fixable reporting issue, but it is load-bearing for the precision of the paper's headline number.","section":"§IV-D"}],"minor_comments":[{"comment":"The text says 'while testing 155 correlations' but the actual number of pairwise tests is 902; please rephrase to avoid confusion.","section":"§IV-D"},{"comment":"There is a typo 'predoGitHub' in the External Validity paragraph; it should be 'predominantly GitHub' or similar.","section":"§VII"},{"comment":"The label 'Not tree: 36' is unclear; the exclusion criterion is 'significantly fewer connections than components,' which is not exactly 'not a tree' because a tree with N nodes has N-1 edges and many graphs with N-1 edges are trees; consider renaming the category to 'Too few connections' for accuracy.","section":"Figure 2"},{"comment":"The sentence 'the centrality of microservices are derived' should agree in number; use 'is derived'.","section":"§VI"},{"comment":"The manual package-to-microservice mapping is described briefly; given that this mapping determines the aggregation of all software metrics, a short example and a description of how ambiguous packages (e.g., shared utility packages) were handled would improve replicability.","section":"§IV-C3"},{"comment":"The interpretation of the negative correlation with security rating is confusing: 'high centrality score correlates to poor security' while 'lower security remediation effort is considered better' — please clarify the direction of the security rating scale and the remediation effort so the reader can follow the argument.","section":"§V-C"}],"recommendation":"major_revision","confidential_remarks":"The paper is within scope and the replication package is a strength. The main concern is whether the empirical chain from source code to centrality scores is clean enough to support the strong conclusion; the authors' own threats section acknowledges the false-negative problem but does not test it. I believe the paper can be made publishable with additional sensitivity, clustering, and multiple-comparison analyses, so I recommend major revision rather than rejection. No concerns about novelty or citation practices."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Worth a serious look. This is the first systematic attempt I know of to correlate a broad set of network centrality measures with classical size/complexity/quality metrics on real microservice projects, and it is transparent enough that you can see where the weak links are. The replication package exists, the dataset construction is described in unusual detail, and the main result is a mostly null result: 282 of 902 correlations are weak-to-moderate, and the strongest positive ones (public methods vs degree centrality) are largely by construction because the dependency graph is built from public API calls. That is a useful negative result, not a flashy one.\n\nThe paper does well on honesty. It reports the 112-to-24 project exodus, the acknowledged false negatives in Code2DFD, the manual package-to-service mapping, and the decision to drop disconnected nodes and single-connection databases. It distinguishes construction-driven correlations from substantive ones. That is more than most exploratory SE papers do.\n\nThe soft spots are real but mostly addressable. First, the final sample is 53 services from 13 systems; the selection cascade from 112 projects means the retained systems may be the easiest to reconstruct, and the paper does not test whether reconstruction quality correlates with the software metrics used in the correlations. The stress-test concern about false negatives is not resolved: if services with many classes or complex wiring lose more edges, the negative correlations with size/complexity are exactly what you would expect from measurement error, not from architecture. Second, 902 tests at alpha=0.01 without multiple-comparison control means some significant cells are false positives; the authors justify the choice but do not provide confidence intervals or a sensitivity analysis. Third, the ratio-based centrality proposal for anti-pattern detection is a speculation, not a validated claim.\n\nNone of this sinks the paper. The central claim — that centrality is only weakly correlated with traditional metrics except where the graph construction makes it so — is plausible and likely survives correction. But the specific negative correlations should not be interpreted as architectural findings until the FN-bias test is done.\n\nI would send this to peer review. It deserves referee time, and the authors are capable of addressing the concerns. For a reading group it is a good case study in how measurement error can masquerade as a negative result.","headline":"First systematic correlation of centrality with standard software metrics on real microservices; a useful negative result, but the false-negative bias in reconstructed graphs needs testing before the specific correlations are trusted.","tokens_in":17938,"tokens_out":2861,"would_cite":true,"duration_ms":26927,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"Network centrality metrics capture architectural role that traditional software metrics do not, so they can complement code metrics in detecting microservice anti-patterns.","keywords":["microservice architecture","centrality metrics","service dependency graph","software metrics","anti-pattern detection","static analysis","correlation analysis"],"falsifier":"Compare the reconstructed service dependency graphs against manually verified or runtime-derived call graphs for the same projects: if the rate of missing connections correlates with service size or complexity, the reported correlation pattern could be an artifact of incomplete reconstruction rather than a property of the systems.","tokens_in":16969,"feed_emoji":"🕸️","tokens_out":4243,"duration_ms":37479,"temperature":0.7,"pith_summary":"The paper asks whether a microservice's position in its dependency graph reveals something that traditional code metrics do not. It reconstructs service dependency graphs for open-source Java-based microservice projects, computes eleven centrality scores for 53 microservices, and correlates them with 155 size, complexity, and quality metrics. Of 902 computed correlations, only 282 are statistically significant, and most of those are weak to moderate. The paper concludes that centrality gives a largely independent perspective on microservice architecture, making it useful for spotting architectural anti-patterns such as hub-like, nano, and mega services.","feed_headline":"Centrality reveals what code metrics miss in microservices","feed_subtitle":"Network position adds an architectural view in 53 microservices, with only weak ties to code size, complexity, and quality.","key_machinery":"The load-bearing object is the Service Dependency Graph (SDG), a directed graph whose nodes are microservices and whose edges are statically reconstructed service-to-service calls. On this graph the paper computes eleven centrality scores, including degree, betweenness, closeness, eigenvector, load, information, harmonic, and subgraph centrality, and correlates them with code metrics aggregated to the service level. The SDG structure explains the correlations that do appear: a service is central because it exposes public methods that other services call, so call-based centrality and public-method counts are tied to the same underlying edges.","core_discovery":"The central claim is that microservice centrality metrics are weak to moderately correlated with traditional software metrics when the correlation is statistically significant, except where the correlation arises directly from the structure of the service dependency graph. A central microservice tends to expose many public methods while having few private or protected methods, low inheritance complexity, lower complexity, and fewer quality violations, consistent with small, API-driven services. The paper argues that centrality therefore encodes architectural role and semantics rather than code structure, so it supplements rather than duplicates existing metrics. It also finds that subgraph centrality behaves differently from the other centrality scores and correlates with security-related quality metrics, possibly indicating a service's attack surface.","pith_inferences":["If the weak-correlation result generalizes, centrality could serve as a leading indicator of architectural degradation that appears before code smells or quality violations.","The reconstruction-error assumption could be tested directly by comparing statically reconstructed dependency graphs with runtime call graphs from tracing or instrumentation on the same systems.","The negative correlation between centrality and duplicated blocks may hide coupling through shared libraries, a mechanism the paper raises but does not confirm.","Because the analysis covers 53 services from 13 open-source systems, the results are a strong motivation for wider empirical testing rather than a settled law of microservice architecture."],"forward_implications":["Centrality metrics can be used alongside traditional software metrics to detect anti-patterns such as hub-like, nano, and mega services.","Ratio-based centralities such as normalized eigenvector or betweenness centrality give comparable thresholds across different systems, unlike raw call counts.","Subgraph centrality warrants further investigation as an indicator of security risk and attack surface in microservice architectures.","Weak correlations imply that centrality-based testing and refactoring priorities may target different services than size- or complexity-based approaches.","Tracking centrality over time could reveal architectural degradation before code-level smells become visible."],"supporting_citations":[{"why":"Supplies Code2DFD, the tool that reconstructs the service dependency graphs from source code.","marker":"[21]"},{"why":"Provides the comparison that identifies the reconstruction tool as generalizable and reliable enough for this study.","marker":"[20]"},{"why":"Contributes one of the four merged datasets of open-source microservice projects.","marker":"[28]"},{"why":"Contributes the microSecEnD dataset of manually verified microservice dataflow diagrams.","marker":"[30]"},{"why":"Provides the filtered open-source microservice dataset used for project selection.","marker":"[31]"},{"why":"Provides the Java Spring microservice feature dataset used for project selection.","marker":"[32]"},{"why":"The closest prior work, computing centrality on a service dependency graph; the paper extends it by correlating centrality with software metrics across many systems.","marker":"[6]"},{"why":"Supplies the interpretation scale used to classify Spearman correlation strengths as weak, moderate, strong, or perfect.","marker":"[63]"}],"fun_headline_variants":["Centrality metrics reveal what code metrics miss","Network position adds architectural insight to microservices","Ratio centrality flags microservice anti-patterns","Centrality vs code metrics: new microservice view","Subgraph centrality: deeper study needed for quality"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The retained 24 reconstructed graphs are assumed to have missing connections that are unrelated to each service's size, complexity, or quality, so the computed centralities are not biased by reconstruction errors.","fun_headline_variants_meta":{"raw":{"variants":["Centrality metrics reveal what code metrics miss","Network position adds architectural insight to microservices","Ratio centrality flags microservice anti-patterns","Centrality vs code metrics: new microservice view","Subgraph centrality: deeper study needed for quality"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000338,"raw_usage":{"total_tokens":1846,"prompt_tokens":903,"completion_tokens":943,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":519,"completion_tokens_details":{"reasoning_tokens":873}},"tokens_in":519,"tokens_out":943,"duration_ms":8177,"temperature":1.0,"reasoning_tokens":873,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T15:51:01.437307+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Compare the reconstructed service dependency graphs against manually verified or runtime-derived call graphs for the same projects: if the rate of missing connections correlates with service size or complexity, the reported correlation pattern could be an artifact of incomplete reconstruction rather than a property of the systems.","supporting_citations":[{"cited_title":"Comparison of Static Analysis Architecture Recovery Tools for Microservice Applications","cited_arxiv_id":"2412.08352","evidence_quote":"Supplies Code2DFD, the tool that reconstructs the service dependency graphs from source code."},{"cited_title":"Comparison of Static Analysis Architecture Recovery Tools for Microservice Applications","cited_arxiv_id":"2403.06941","evidence_quote":"Provides the comparison that identifies the reconstruction tool as generalizable and reliable enough for this study."},{"cited_title":"Centrality measures in networks,","cited_arxiv_id":null,"evidence_quote":"Contributes one of the four merged datasets of open-source microservice projects."},{"cited_title":"Towards a reference dataset of microservice-based applications,","cited_arxiv_id":null,"evidence_quote":"Contributes the microSecEnD dataset of manually verified microservice dataflow diagrams."},{"cited_title":"Vii. note on regression and inheritance in the case of two parents,","cited_arxiv_id":null,"evidence_quote":"Supplies the interpretation scale used to classify Spearman correlation strengths as weak, moderate, strong, or perfect."}],"review_version":1}