Effects of the number of developers on code quality in open source software

Norick, Brandon; Krohn, Justin; Howard, Eben; Welna, Ben; Izurieta, Clemente

doi:10.1145/1852786.1852864

Cited by 11 publications

(14 citation statements)

References 3 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…These results contrast with related work which found that software quality is influenced by the size of the code base [14] or the number of developers [8]. But they are in accordance with Weyuker et al [42] and Norick et al [30], who found that the number of developers has no major impact on code quality. Additionally, they agree with Ahmed et al [4] who found that code quality is not affected by code base size.…”

Section: Results Discussioncontrasting

confidence: 58%

“…Samoladas et al [36] and Stamelos et al [38] present studies on code quality of open-source code. Norick et al [30] present a study on open-source code, investigating the impact of team size on code quality. All three papers also use static analysis to measure code quality, they use different metrics, which we consider less suitable for maintainability.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Evaluating Maintainability Prejudices with a Large-Scale Study of Open-Source Projects

Roehm¹,

Veihelmann²,

Wagner

et al. 2018

Lecture Notes in Business Information Processing

View full text Add to dashboard Cite

Exaggeration or context changes can render maintainability experience into prejudice. For example, JavaScript is often seen as least elegant language and hence of lowest maintainability. Such prejudice should not guide decisions without prior empirical validation. We formulated 10 hypotheses about maintainability based on prejudices and test them in a large set of open-source projects (6,897 GitHub repositories, 402 million lines, 5 programming languages). We operationalize maintainability with five static analysis metrics. We found that JavaScript code is not worse than other code, Java code shows higher maintainability than C# code and C code has longer methods than other code. The quality of interface documentation is better in Java code than in other code. Code developed by teams is not of higher and large code bases not of lower maintainability. Projects with high maintainability are not more popular or more often forked. Overall, most hypotheses are not supported by open-source data.

show abstract

Section: Results Discussioncontrasting

confidence: 58%

Section: Introductionmentioning

confidence: 99%

Evaluating Maintainability Prejudices with a Large-Scale Study of Open-Source Projects

Roehm¹,

Veihelmann²,

Wagner

et al. 2018

Lecture Notes in Business Information Processing

View full text Add to dashboard Cite

show abstract

“…The final sample consists of 11 projects composed of 66 deployed SCs . Similarly, 11 projects written in C/C++ were studied in Norick et al given constraints such as the lack of consistency in stored information from one project to another and challenges in accessing the source code repository for a project.…”

Section: Methodsmentioning

confidence: 99%

An empirical analysis of source code metrics and smart contract resource consumption

Ajienka

Vangorp

Capiluppi

2020

J Software Evolu Process

View full text Add to dashboard Cite

A smart contract (SC) is a programme stored in the Ethereum blockchain by a contract-creation transaction. SC developers deploy an instance of the SC and attempt to execute it in exchange for a fee, paid in Ethereum coins (Ether). If the computation needed for their execution turns out to be larger than the effort proposed by the developer (i.e., the gasLimit), their client instantiation will not be completed successfully. In this paper, we examine SCs from 11 Ethereum blockchain-oriented software projects hosted on GitHub.com, and we evaluate the resources needed for their deployment (i.e., the gasUsed). For each of these contracts, we also extract a suite of object-oriented metrics, to evaluate their structural characteristics. Our results show a statistically significant correlation between some of the object-oriented (OO) metrics and the resources consumed on the Ethereum blockchain network when deploying SCs. This result has a direct impact on how Ethereum developers engage with a SC: evaluating its structural characteristics, they will be able to produce a better estimate of the resources needed to deploy it. Other results show specific source code metrics to be prioritised based on application domains when the projects are clustered based on common themes. KEYWORDS abstract syntax-tree (AST), blockchain-oriented software (BOS), Chidamber and Kemerer (C&K), object-oriented (OO), object-oriented programming (OOP), smart contract (SC) 1 INTRODUCTION A blockchain is a shared ledger that stores transactions in a decentralised 1 peer-to-peer network of computers also known as nodes. Blockchain transactions can be composed of contract creation transactions and contract function invoking transactions. The former deploys and records a smart contract (SC) on the blockchain, and the latter causes the execution of a contract functionality. 2,3 The third transaction type is the token or cryptocurrency transfer transaction such as Bitcoin transfers on the Bitcoin Blockchain or Ether transfers on the Ethereum Blockchain. As a whole, the blockchain technology provides a decentralised, trustless platform that combines transparency, immutability and consensus properties to enable secure, pseudo-anonymous transactions. SCs are the programmes stored in a blockchain by a contract-creation transaction. In the last few years, SCs have been used in different scenarios: in voting platforms to secure votes; to automatically process insurance claims according to agreed terms and postal companies for payments on delivery. 5 Porru et al 6 defined the term blockchain-oriented software (BOS) as a software that contributes to the realization of a blockchain project. This definition includes both blockchain platforms (or networks), such as Bitcoin and Ethereum, and general blockchain software commonly referred to as decentralised apps (DApps). 7 This is an open access article under the terms of the Creative Commons Attribution-NonCommercial License, which permits use, distribution and reproduction in any medium, provided the original work...

show abstract

“…For example Norick et al use eleven open source software projects, to determine if the number of committing developers affects the quality of a software system. As a result, they could not find significant evidence to claim that the number of committing developers affects the quality of software [34]. Furthermore, Pendharkar and Rodger investigate the impact of team size on the software development effort using over 200 software projects and conclude that when the size of the team increases, no significant software effort improvements are seen [36].…”

Section: Previous Workmentioning

confidence: 98%

Software defect prediction using Bayesian networks

2012

View full text Add to dashboard Cite

There are lots of different software metrics discovered and used for defect prediction in the literature. Instead of dealing with so many metrics, it would be practical and easy if we could determine the set of metrics that are most important and focus on them more to predict defectiveness. We use Bayesian networks to determine the probabilistic influential relationships among software metrics and defect proneness. In addition to the metrics used in Promise data repository, we define two more metrics, i.e. NOD for the number of developers and LOCQ for the source code quality. We extract these metrics by inspecting the source code repositories of the selected Promise data repository data sets. At the end of our modeling, we learn the marginal defect proneness probability of the whole software system, the set of most effective metrics, and the influential relationships among metrics and defectiveness. Our experiments on nine open source Promise data repository data sets show that response for class (RFC), lines of code (LOC), and lack of coding quality (LOCQ) are the most effective metrics whereas coupling between objects (CBO), weighted method per class (WMC), and lack of cohesion of methods (LCOM) are less effective metrics on defect proneness. Furthermore, number of children (NOC) and depth of inheritance tree (DIT) have very limited effect and are untrustworthy. On the other hand, based on the experiments on Poi, Tomcat, and Xalan data sets, we observe that there is a positive correlation between the number of developers (NOD) and the level of defectiveness. However, further investigation involving a greater number of projects is needed to confirm our findings.

show abstract

Effects of the number of developers on code quality in open source software

Cited by 11 publications

References 3 publications

Evaluating Maintainability Prejudices with a Large-Scale Study of Open-Source Projects

Evaluating Maintainability Prejudices with a Large-Scale Study of Open-Source Projects

An empirical analysis of source code metrics and smart contract resource consumption

Software defect prediction using Bayesian networks

Contact Info

Product

Resources

About