Datta S.

Larman C.

English

DATTA, Subhajit

Institutional Knowledge at Singapore Management University

Singapore Management University Institutional Knowledge at Singapore Management University Research Collection School Of Information Systems School of Information Systems 11-2014 Perspectives on task ownership in mobile operating system development [invited talk] Subhajit DATTA Singapore Management University, subhajitd@smu.edu.sg Follow this and additional works at: https://ink.library.smu.edu.sg/sis_research  Part of the Databases and Information Systems Commons, and the Software Engineering Commons Citation 1 This Conference Proceeding Article is brought to you for free and open access by the School of Information Systems at Institutional Knowledge at Singapore Management University. It has been accepted for inclusion in Research Collection School Of Information Systems by an authorized administrator of Institutional Knowledge at Singapore Management University. For more information, please email cherylds@smu.edu.sg. Perspectives on Task Ownership in Mobile OperatingSystem Development (Invited Talk)Subhajit DattaSingapore University of Technology and Designsubhajit.datta@acm.orgABSTRACTThere can be little contention about Stroustrup’s epigram-matic remark: our civilization runs on software. However acaveat is increasingly due, much of the software that runs ourcivilization, runs on mobile devices today. Mobile operatingsystems have come to play a preeminent role in the ubiquityand utility of such devices. The development ecosystem ofAndroid - one of the most popular mobile operating sys-tems - presents an interesting context for studying whetherand how collaboration dynamics in mobile development dif-fer from conventional software development. In this paper,we examine factors that influence task ownership in Androiddevelopment. Our results can inform project governance de-cisions at the individual and organizational levels.Categories and Subject DescriptorsD.2.9 [Software Engineering]: Management—Life cycleGeneral TermsExperimentationKeywordsAndroid, reviews, code changes, merging1. INTRODUCTIONBackground: Deciding who does what in the assignmentof functionality to software components has been recognizedas a “desert island skill” [6]. Similarly, in the delegation oftasks to members of a software development team there aremany open questions as to what constitutes the most opti-mal distribution of responsibility. Large scale software sys-tems are being increasingly built out of interactions betweenmany members of distributed teams. In such ecosystems,whether developers should be encouraged to focus closelyon tasks they own, or participate widely in shared responsi-bilities with peers, needs to be better understood.Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.DeMobile’14 , November 17, 2014, Hong Kong, ChinaCopyright 2014 ACM 978-1-4503-3225-5/14/11 ...$15.00.Related work: There have been studies on whether moreeyeballs indeed make a bug shallow [4], and the influences onresolution times of defects [5] or modification requests [3].In addition to bug resolution or implementation of modi-fication requests, another critical activity underpins muchof iterative software development – collective review of codechanges. In this paper, we study how developer involvementin such review activities relate to the time taken for corre-sponding code changes to be integrated into the main codebase (i.e. “merged”), using data from Android development.The wide currency of Android as a popular operating systemfor mobile devices makes it imperative that the code baseundergoes frequent refinements [1]. An essential element ofthis refinement process is the production and review of newunits of code, and based on their review outcome by devel-opers, arrival at the decision on whether or not to mergethe code. In the context of the Android review data, weexamine the following hypothesis in this paper:Hypothesis: Code changes owned by developers who areinvolved in more code reviews take higher amount of time tobe merged.2. METHODOLOGYTo validate this hypotheses, we develop a multiple lin-ear regression model using data on merged Android reviewsfrom a publicly accessible repository1. Lack of space pre-vents a detailed discussion of the data-set; interested readersmay refer to the curation and structure of the data in [7].In the following discussion, a “review” will be taken to meana unit of code change that is scrutinized by multiple devel-opers (“reviewers”), and based on “approval” scores given byeach of them, a decision is taken whether or not to “merge”the unit with the main body of code.As the dependent variable of the model, TimeToMergewas calculated as the elapsed time between the time-stampof review creation and the time-stamp of its last updat-ing. As the independent variable, we took OwnerRe-viewCount ; for each review (say x), this is the number ofreviews the owner of x has reviewed and given an approvalscore. The OwnerReviewCount is taken to reflect the levelof involvement of a review’s owner in the overall review pro-cess. To isolate the relation between the dependent andindependent variables, we identified the following controlvariables which capture the peripheral effects on the in-dependent variable: ExtentOfCodeChange - calculated asthe number of patches associated with a review; Quality-OfChange - the median of the approval scores received by1https://github.com/mmukadam/gerrit-miner.gitPermission to make digital or hard copies of part or all of this work for personal orclassroom use is gr nted without fee p ovided that copies are no made or dist ibutedfor profit or commercial advantage and that copies bear this notice and the full citationon the first page. Copyrights for third-party components of this work must be honored.For all other uses, contact the Owner/Author.Copyright is held by the author/owner(s).D Mobile’14, N vember 17, 2014, Hong Kong, ChinaAC 978- -4503-3225-5/ 4/11http://dx.doi.org/10.1145/2661694.266170211Table 1: Descriptive statistics of model variablesMean Stdev Skew KurtTimeToMerge 17.61 21.48 2.31 6.25ExtentOfCodeChange 2.50 2.01 2.98 4.44QualityOfChange 0.43 0.58 1.13 0.35DependencyLevel 300.52 192.55 0.65 0.13NoOfReviewers 4.70 1.79 1.50 3.98NoOfNnOwnrComnts 2.53 1.19 2.89 6.9OwnerWorkload 60.63 67.02 1.14 0.13OwnerReviewCount 190.07 228.18 2.01 5.51Table 2: Results of regression for the effects on bugresolution time.(Superscripts ’∗∗∗’, ’∗∗’, ’∗’, ’†’ denotep ≤ 0.0001, p ≤ 0.001, p ≤ 0.01, p ≤ 0.05, respectively)I IIBase model Refined modelIntercept −2.86† −1.89(1.65) (1.65)Control variablesExtentOfCodeChange 1.01∗∗∗ 1.12∗∗∗(0.29) (0.28)QualityOfChange −4.02∗∗∗ −2.96∗∗∗(0.763) (0.75)DependencyLevel 0.005∗ 0.004∗(0.002) (0.002)NoOfReviewers 1.235∗∗ 1.086∗∗∗(0.260) (0.25)NoOfNnOwnrComnts 4.45∗∗∗ 3.6∗∗∗(0.53) (0.52)OwnerWorkload 0.017∗∗∗ 0.054∗∗∗(0.006) (0.006)Independent variableOwnerReviewCount −0.024∗∗∗(0.002)N 2243 2243R2 0.186 0.232df 2236 2235F 85.2 96.4p < 0.001 < 0.001a review; DependencyLevel - calculated as the degree cen-trality of review in a network based on review similarity;NoOfReviewers - the number of different developers partic-ipating in the review process; NoOfNnOwnrComnts - thenumber of comments on a particular review by developerswho do not own it;OwnerWorkload - for each review, thenumber of reviews owned by its owner. TimeToMerge andNoOfNnOwnrComnts are transformed by taking the squareroot, to be closer to normal distribution.Table 1 gives the descriptive statistics of the above modelvariables. To understand the relation between the depen-dent and independent variable, after accounting for the ef-fects of the control variables, we first build a base model withonly the control variables and the dependent variable, andthen augment it into a refined model by adding the indepen-dent variable; the corresponding columns of Table 2 gives theparameters of these models. The underlying assumptions ofmultiple linear regression were found to be within reasonablelimits for our analysis.3. RESULTS AND DISCUSSIONAs we observe from Table 2, the refined model representsa better fit to the data compared to the base model andboth the models are statistically significant. Adding theindependent variable increases the R2 value by 25%. Inboth the models, the variables are statistically significant atα = 0.05.The threat to construct validity comes from our defini-tion of similarity between reviews using a Latent DirichletAllocation [2] based approach, as well as the calculation ofsome of the model variables based on available data. Sincewe use curated data from a single source, there is no notablethreat to internal validity. As we have only studied datafrom a single source and the R2 values indicate there areinfluences on the independent variable which have not beencaptured, we recognize that threats to external validityare present in the study. Our results establish reliabilityas they can be reproduced, given access to the data-set. Andfinally, as this is an observational study rather than a con-trolled experiment, correlation can not be taken to indicatecausation.From the model parameters, we observe that higher Own-erReviewCount relates to lower TimeToMerge; thus our hy-pothesis is not supported by the empirical evidence. This isa counter-intuitive result, especially as we find that higherOwnerWorkload does indeed relate to more time being re-quired for merging code changes. In contrast, higher involve-ment in reviewing appears to make developers more aware ofthe development ecosystem, leading to more effective own-ership of code changes, which is reflected in quicker mergingof code.4. REFERENCES[1] Asaduzzaman, M., Bullock, M., Roy, C., andSchneider, K. Bug introducing changes: A case studywith android. In Mining Software Repositories (MSR),2012 9th IEEE Working Conference on (June 2012),pp. 116–119.[2] Blei, D., Ng, A., and Jordan, M. Latent dirichletallocation. Journal of Machine Learning Research 3(2003), 993–1022.[3] Cataldo, M., Wagstrom, P. A., Herbsleb, J. D.,and Carley, K. M. Identification of coordinationrequirements: implications for the design ofcollaboration and awareness tools. In Proceedings of the2006 20th anniversary conference on Computersupported cooperative work (New York, NY, USA,2006), CSCW ’06, ACM, p. 353âĂŞ362.[4] Datta, S., Sarkar, P., Das, S., Sreshtha, S.,Lade, P., and Majumder, S. How many eyeballs doesa bug need? an empirical validation of linusâĂŹ law. InAgile Processes in Software Engineering and ExtremeProgramming, G. Cantone and M. Marchesi, Eds.,vol. 179 of LNBIP. Springer International Publishing,2014, pp. 242–250.[5] Koru, A. G., and Liu, H. Building defect predictionmodels in practice. IEEE Softw. 22, 6 (Nov. 2005),23âĂŞ29.[6] Larman, C. Applying UML and Patterns. PrenticeHall, 1997.[7] Mukadam, M., Bird, C., and Rigby, P. C. Gerritsoftware code review data from android. In Proceedingsof the 10th Working Conference on Mining SoftwareRepositories (Piscataway, NJ, USA, 2013), MSR ’13,IEEE Press, pp. 45–48.12

Perspectives on task ownership in mobile operating system development [invited talk]

Subhajit Datta

Crossref

Perspectives on task ownership in mobile operating system development (invited talk)

Singapore Management University 
Institutional Knowledge at Singapore Management University 
Research Collection School Of Information 
Systems School of Information Systems 
11-2014 
Perspectives on task ownership in mobile operating system 
development [invited talk] 
Subhajit DATTA 
Singapore Management University, subhajitd@smu.edu.sg 
Follow this and additional works at: https://ink.library.smu.edu.sg/sis_research 
 Part of the Databases and Information Systems Commons, and the Software Engineering Commons 
Citation 
1 
This Conference Proceeding Article is brought to you for free and open access by the School of Information 
Systems at Institutional Knowledge at Singapore Management University. It has been accepted for inclusion in 
Research Collection School Of Information Systems by an authorized administrator of Institutional Knowledge at 
Singapore Management University. For more information, please email cherylds@smu.edu.sg. 
Perspectives on Task Ownership in Mobile Operating
System Development (Invited Talk)
Subhajit Datta
Singapore University of Technology and Design
subhajit.datta@acm.org
ABSTRACT
There can be little contention about Stroustrup’s epigram-
matic remark: our civilization runs on software. However a
caveat is increasingly due, much of the software that runs our
civilization, runs on mobile devices today. Mobile operating
systems have come to play a preeminent role in the ubiquity
and utility of such devices. The development ecosystem of
Android - one of the most popular mobile operating sys-
tems - presents an interesting context for studying whether
and how collaboration dynamics in mobile development dif-
fer from conventional software development. In this paper,
we examine factors that influence task ownership in Android
development. Our results can inform project governance de-
cisions at the individual and organizational levels.
Categories and Subject Descriptors
D.2.9 [Software Engineering]: Management—Life cycle
General Terms
Experimentation
Keywords
Android, reviews, code changes, merging
1. INTRODUCTION
Background: Deciding who does what in the assignment
of functionality to software components has been recognized
as a “desert island skill” [6]. Similarly, in the delegation of
tasks to members of a software development team there are
many open questions as to what constitutes the most opti-
mal distribution of responsibility. Large scale software sys-
tems are being increasingly built out of interactions between
many members of distributed teams. In such ecosystems,
whether developers should be encouraged to focus closely
on tasks they own, or participate widely in shared responsi-
bilities with peers, needs to be better understood.
Permission to make digital or hard copies of all or part of this work for
personal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that copies
bear this notice and the full citation on the first page. To copy otherwise, to
republish, to post on servers or to redistribute to lists, requires prior specific
permission and/or a fee.
DeMobile’14 , November 17, 2014, Hong Kong, China
Copyright 2014 ACM 978-1-4503-3225-5/14/11 ...$15.00.
Related work: There have been studies on whether more
eyeballs indeed make a bug shallow [4], and the influences on
resolution times of defects [5] or modification requests [3].
In addition to bug resolution or implementation of modi-
fication requests, another critical activity underpins much
of iterative software development – collective review of code
changes. In this paper, we study how developer involvement
in such review activities relate to the time taken for corre-
sponding code changes to be integrated into the main code
base (i.e. “merged”), using data from Android development.
The wide currency of Android as a popular operating system
for mobile devices makes it imperative that the code base
undergoes frequent refinements [1]. An essential element of
this refinement process is the production and review of new
units of code, and based on their review outcome by devel-
opers, arrival at the decision on whether or not to merge
the code. In the context of the Android review data, we
examine the following hypothesis in this paper:
Hypothesis: Code changes owned by developers who are
involved in more code reviews take higher amount of time to
be merged.
2. METHODOLOGY
To validate this hypotheses, we develop a multiple lin-
ear regression model using data on merged Android reviews
from a publicly accessible repository1. Lack of space pre-
vents a detailed discussion of the data-set; interested readers
may refer to the curation and structure of the data in [7].
In the following discussion, a “review” will be taken to mean
a unit of code change that is scrutinized by multiple devel-
opers (“reviewers”), and based on “approval” scores given by
each of them, a decision is taken whether or not to “merge”
the unit with the main body of code.
As the dependent variable of the model, TimeToMerge
was calculated as the elapsed time between the time-stamp
of review creation and the time-stamp of its last updat-
ing. As the independent variable, we took OwnerRe-
viewCount ; for each review (say x), this is the number of
reviews the owner of x has reviewed and given an approval
score. The OwnerReviewCount is taken to reflect the level
of involvement of a review’s owner in the overall review pro-
cess. To isolate the relation between the dependent and
independent variables, we identified the following control
variables which capture the peripheral effects on the in-
dependent variable: ExtentOfCodeChange - calculated as
the number of patches associated with a review; Quality-
OfChange - the median of the approval scores received by
1https://github.com/mmukadam/gerrit-miner.git
Permission to make digital or hard copies of part or all of this work for personal or
classroom use is gr nted without fee p ovided that copies are no made or dist ibuted
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for third-party components of this work must be honored.
For all other uses, contact the Owner/Author.
Copyright is held by the author/owner(s).
D Mobile’14, N vember 17, 2014, Hong Kong, China
AC 978- -4503-3225-5/ 4/11
http://dx.doi.org/10.1145/2661694.2661702
11
Table 1: Descriptive statistics of model variables
Mean Stdev Skew Kurt
TimeToMerge 17.61 21.48 2.31 6.25
ExtentOfCodeChange 2.50 2.01 2.98 4.44
QualityOfChange 0.43 0.58 1.13 0.35
DependencyLevel 300.52 192.55 0.65 0.13
NoOfReviewers 4.70 1.79 1.50 3.98
NoOfNnOwnrComnts 2.53 1.19 2.89 6.9
OwnerWorkload 60.63 67.02 1.14 0.13
OwnerReviewCount 190.07 228.18 2.01 5.51
Table 2: Results of regression for the effects on bug
resolution time.(Superscripts ’∗∗∗’, ’∗∗’, ’∗’, ’†’ denote
p ≤ 0.0001, p ≤ 0.001, p ≤ 0.01, p ≤ 0.05, respectively)
I II
Base model Refined model
Intercept −2.86† −1.89
(1.65) (1.65)
Control variables
ExtentOfCodeChange 1.01∗∗∗ 1.12∗∗∗
(0.29) (0.28)
QualityOfChange −4.02∗∗∗ −2.96∗∗∗
(0.763) (0.75)
DependencyLevel 0.005∗ 0.004∗
(0.002) (0.002)
NoOfReviewers 1.235∗∗ 1.086∗∗∗
(0.260) (0.25)
NoOfNnOwnrComnts 4.45∗∗∗ 3.6∗∗∗
(0.53) (0.52)
OwnerWorkload 0.017∗∗∗ 0.054∗∗∗
(0.006) (0.006)
Independent variable
OwnerReviewCount −0.024∗∗∗
(0.002)
N 2243 2243
R2 0.186 0.232
df 2236 2235
F 85.2 96.4
p < 0.001 < 0.001
a review; DependencyLevel - calculated as the degree cen-
trality of review in a network based on review similarity;
NoOfReviewers - the number of different developers partic-
ipating in the review process; NoOfNnOwnrComnts - the
number of comments on a particular review by developers
who do not own it;OwnerWorkload - for each review, the
number of reviews owned by its owner. TimeToMerge and
NoOfNnOwnrComnts are transformed by taking the square
root, to be closer to normal distribution.
Table 1 gives the descriptive statistics of the above model
variables. To understand the relation between the depen-
dent and independent variable, after accounting for the ef-
fects of the control variables, we first build a base model with
only the control variables and the dependent variable, and
then augment it into a refined model by adding the indepen-
dent variable; the corresponding columns of Table 2 gives the
parameters of these models. The underlying assumptions of
multiple linear regression were found to be within reasonable
limits for our analysis.
3. RESULTS AND DISCUSSION
As we observe from Table 2, the refined model represents
a better fit to the data compared to the base model and
both the models are statistically significant. Adding the
independent variable increases the R2 value by 25%. In
both the models, the variables are statistically significant at
α = 0.05.
The threat to construct validity comes from our defini-
tion of similarity between reviews using a Latent Dirichlet
Allocation [2] based approach, as well as the calculation of
some of the model variables based on available data. Since
we use curated data from a single source, there is no notable
threat to internal validity. As we have only studied data
from a single source and the R2 values indicate there are
influences on the independent variable which have not been
captured, we recognize that threats to external validity
are present in the study. Our results establish reliability
as they can be reproduced, given access to the data-set. And
finally, as this is an observational study rather than a con-
trolled experiment, correlation can not be taken to indicate
causation.
From the model parameters, we observe that higher Own-
erReviewCount relates to lower TimeToMerge; thus our hy-
pothesis is not supported by the empirical evidence. This is
a counter-intuitive result, especially as we find that higher
OwnerWorkload does indeed relate to more time being re-
quired for merging code changes. In contrast, higher involve-
ment in reviewing appears to make developers more aware of
the development ecosystem, leading to more effective own-
ership of code changes, which is reflected in quicker merging
of code.
4. REFERENCES
[1] Asaduzzaman, M., Bullock, M., Roy, C., and
Schneider, K. Bug introducing changes: A case study
with android. In Mining Software Repositories (MSR),
2012 9th IEEE Working Conference on (June 2012),
pp. 116–119.
[2] Blei, D., Ng, A., and Jordan, M. Latent dirichlet
allocation. Journal of Machine Learning Research 3
(2003), 993–1022.
[3] Cataldo, M., Wagstrom, P. A., Herbsleb, J. D.,
and Carley, K. M. Identification of coordination
requirements: implications for the design of
collaboration and awareness tools. In Proceedings of the
2006 20th anniversary conference on Computer
supported cooperative work (New York, NY, USA,
2006), CSCW ’06, ACM, p. 353âĂŞ362.
[4] Datta, S., Sarkar, P., Das, S., Sreshtha, S.,
Lade, P., and Majumder, S. How many eyeballs does
a bug need? an empirical validation of linusâĂŹ law. In
Agile Processes in Software Engineering and Extreme
Programming, G. Cantone and M. Marchesi, Eds.,
vol. 179 of LNBIP. Springer International Publishing,
2014, pp. 242–250.
[5] Koru, A. G., and Liu, H. Building defect prediction
models in practice. IEEE Softw. 22, 6 (Nov. 2005),
23âĂŞ29.
[6] Larman, C. Applying UML and Patterns. Prentice
Hall, 1997.
[7] Mukadam, M., Bird, C., and Rigby, P. C. Gerrit
software code review data from android. In Proceedings
of the 10th Working Conference on Mining Software
Repositories (Piscataway, NJ, USA, 2013), MSR ’13,
IEEE Press, pp. 45–48.
12


https://ink.library.smu.edu.sg/cgi/viewcontent.cgi?article=6588&context=sis_research

Perspectives on task ownership in mobile operating system development [invited talk]

Abstract

Similar works

Full text

Available Versions

Institutional Knowledge at Singapore Management University

Crossref

Institutional Knowledge at Singapore Management University