Sep 2026· Zenodo (CERN European Organization for Nuclear Research)
Abstract
Background. RewardBench 2 aggregates pairwise preference accuracy across heterogeneous task families (factuality, instruction following, safety, and others). A single leaderboard score can mask systematic subset specialization, yet standard benchmark reporting rarely tests whether accuracy is independent of task category. Methods. We applied CONFIRM, a chi-square test of independence with Cramér's V effect sizing and empirically anchored letter grades, to 174 publicly released reward models. For each model we constructed a 5 × 2 contingency table (subset × correct/incorrect) from published per-prompt scores (n = 1,763 prompts after excluding the non-binary Ties subset). The null hypothesis was that correct/incorrect outcomes are independent of subset category. Grades A–F reflect V magnitude (CONFIRM v2 thresholds); grade I denotes insufficient power. Non-significant results grade F only when power ≥ 0.80 to detect V = 0.10. Results. All 174 models rejected independence at α = 0.05 (all p < 0.02; median V = 0.272, range 0.082–0.467). No model received F or I. Grade distribution: A 36.8% (n = 64), B 50.6% (n = 88), C 11.5% (n = 20), D 1.1% (n = 2). Pooling across models, mean per-subset accuracy was lowest on Precise IF (36.3 per 100) and highest on Safety (75.7 per 100). In 93.1% of models the largest subset gap involved Precise IF as the weakest category; Safety was the strongest endpoint in 70.7% of cases. Conclusions. Published RewardBench 2 reward models exhibit statistically detectable subset heterogeneity at this sample size. Aggregate accuracy therefore understates structured performance imbalance, particularly weakness on precise instruction-following relative to safety-oriented subsets. CONFIRM provides a reproducible heterogeneity diagnostic to be read alongside ranking metrics. Plain-language summary. For all 174 reward models tested, the rate of correct judgments differed across the five task types by more than the prespecified statistical threshold. The direction of the difference was shared: 93.1% of models were weakest on precise instruction-following, and 70.7% were strongest on safety. Each model was tested on 1,763 prompts, enough sensitivity to detect even a small difference had one been present, so a model showing no difference would have been identifiable as such. None did. A single overall leaderboard score does not show this — two models with the same average can differ substantially underneath. This analysis measures whether a model's accuracy is uneven across task types, not which model is best overall, and it identifies a pattern without establishing its cause. Supplementary material. The deposited archive (rewardbench2_validation.zip) contains per-model results, subset breakdowns, contingency cell counts, validation flags, and step-by-step mathematical derivations for all 174 models. Competing interests. The author is affiliated with TraceSeis, Inc., which is developing CONFIRM as a commercial product. This constitutes a competing interest. All results are reproducible from the cited public data and the deposited analysis outputs. AI use disclosure. Generative AI tools were used during preparation of this work, in two distinct roles. For drafting and implementation: Anthropic Claude assisted with manuscript prose; the CONFIRM engine and analysis pipeline were implemented with AI coding tools (Cursor, Anthropic Claude) to the author's specification; and Google Gemini was consulted during writing and analysis runs. For review: Perplexity provided editorial review of a late draft, and xAI Grok was used as a general consistency check. This reflects the author's record of tool use and is not offered as an exhaustive log. Research design, statistical methodology, and interpretation are the author's. Because the analysis software was AI-implemented, every reported statistic was independently recomputed from observed cell counts and checked against pipeline output before reporting; per-model derivations are deposited as confirm_math.html and can be checked by hand. The author takes full responsibility for the contents of this record.
Software startups are newly created companies with no operating history and oriented towards producing cutting-edge products. However, despite the increasing importance of startups in the economy, few scientific studies attempt to address software engineering issues, especially for early-stage startups. If anything, startups need engineering practices of the same level or better than those of larger companies, as their time and resources are more scarce, and one failed project can put them out of business. In this study we aim to improve understanding of the software development strategies employed by startups. We performed this state-of-practice investigation using a grounded theory approach. We packaged the results in the Greenfield Startup Model (GSM), which explains the priority of startups to release the product as quickly as possible. This strategy allows startups to verify product and market fit, and to adjust the product trajectory according to early collected user feedback. The need to shorten time-to-market, by speeding up the development through low-precision engineering activities, is counterbalanced by the need to restructure the product before targeting further growth. The resulting implications of the GSM outline challenges and gaps, pointing out opportunities for future research to develop and validate engineering practices in the startup context.
Carmine Giardino, Nicolò Paternoster, M. Unterkalmsteiner et al.· IEEE Transactions on Softwar...· 179 citations· ⚡14
Software startup companies develop innovative, software-intensive products within limited timeframes and with few resources, searching for sustainable and scalable business models. Software startup ...
M. Unterkalmsteiner, P. Abrahamsson, Xiaofeng Wang et al.· e-Informatica Software Engin...· 157 citations· ⚡17
In the context of software startups, project failure is embraced actively and considered crucial to obtain validated learning that can lead to pivots. A pivot is the strategic change of a business concept, product or the different elements of a business model. A better understanding is needed on different types of pivots and different factors that lead to failures and trigger pivots, for software entrepreneurial teams to make better decisions under chaotic and unpredictable environment. Due to the nascent nature of the topic, the existing research and knowledge on the pivots of software startups are very limited. In this study, we aimed at identifying the major types of pivots that software startups make during their startup processes, and highlighting the factors that fail software projects and trigger pivots. To achieve this, we conducted a case survey study based on the secondary data of the major pivots happened in 49 software startups. 10 pivot types and 14 triggering factors were identified. The findings show that customer need pivot is the most common among all pivot types. Together with customer segment pivot, they are common market related pivots. The major product related pivots are zoom-in and technology pivots. Several new pivot types were identified, including market zoom-in, complete and side project pivots. Our study also demonstrates that negative customer reaction and flawed business model are the most common factors that trigger pivots in software startups. Our study extends the research knowledge on software startup pivot types and pivot triggering factors. Meanwhile it provides practical knowledge to software startups, which they can utilize to guide their effective decisions on pivoting.
Sohaib Shahid Bajwa, Xiaofeng Wang, Anh Nguyen-Duc et al.· Empirical Software Engineeri...· 127 citations· ⚡15
In the context of cloud computing, risks associated with underlying technologies, risks involving service models and outsourcing, and enterprise readiness have been recognized as potential barriers for the adoption. To accelerate cloud adoption, the concrete barriers negatively influencing the adoption decision need to be identified. Our study aims at understanding the impact of technical and security-related barriers on the organizational decision to adopt the cloud. We analyzed data collected through a web survey of 352 individuals working for enterprises consisting of decision makers as well as employees from other levels within an organization. The comparison of adopter and non-adopter sample reveals three potential adoption inhibitor, security, data privacy, and portability. The result from our logistic regression analysis confirms the criticality of the security concern, which results in an up to 26-fold increase in the non-adoption likelihood. Our study underlines the importance of the technical and security perspectives for research investigating the adoption of technology.
Nattakarn Phaphoom, Xiaofeng Wang, S. Samuel et al.· Journal of Systems and Softw...· 111 citations· ⚡8
To compete in this age of disruption, large companies cannot rely on cost efficiency, lead time reduction and quality improvement. They are now looking for ways to innovate like startups. Meanwhile, the awareness and use of the Lean startup approach have grown rapidly amongst the software startup community in recent years. This study investigates how Lean internal startup facilitates software product innovation in large companies and identifies its enablers and inhibitors. A multiple case study approach is followed in the investigation. Two software product innovation projects from two large companies are examined, using a conceptual framework that is based on the method-in-action framework and extended with the previously developed Lean-Internal Corporate Venture model. Seven face-to-face in-depth interviews of the employees with different roles are conducted. Within-case analysis and cross-case comparison are applied to draw the findings from the cases. A generic process flow summarises the common key processes of Lean internal startups. The findings suggest that an internal startup that is initiated management or employees faces different challenges. A list of enablers of applying Lean startup in large companies are identified, including top management support and cross-functional team. Both cases face different inhibitors due to the different process of inception, objective of the team and type of the product. Our contributions are threefold. First, this study is one of the first attempt to investigate the use of Lean startup approach in large companies empirically. Second, the study shows the potential of the method-in-action framework to investigate the Lean startup approach in non-startup context. The third is a general process of Lean internal startup and the evidence of the enablers and inhibitors of implementing it, which are both theory-informed and empirically grounded.
Henry Edison, Nina M. Smørsgård, Xiaofeng Wang et al.· Journal of Systems and Softw...· 78 citations· ⚡6
The application of agile software methods and more recently the integration of Lean practices contribute to the trend of continuous improvement in the software industry. One such area warranting proper empirical evidence is a project’s operational efficiency when using the Kanban method. This short paper takes a new angle and explores waste in the Kanban-driven software development project context. A preliminary research model is presented for helping the consequent replication of the study. The results from the empirical analysis suggest Kanban can be an effective method in visualizing and organizing the current work, but does not prevent waste from creeping in, although the overall project outcome may be successful.
Marko Ikonen, Petri Kettunen, Nilay V. Oza et al.· EUROMICRO Conference on Soft...· 67 citations· ⚡9