Conference PaperPDF Available

The evolution of mobile apps: An exploratory study


Abstract and Figures

As mobile apps continue to grow in popularity, it is important to study their evolution. Lehman's laws of software evolution have been proposed and used to study the evolution of traditional, large software systems (also known as desktop apps). However, do Lehman's laws of software evolution hold for mobile apps?, especially since developing mobile apps presents different challenges compared to the development of desktop apps. In this paper, we examine the applicability of three of Lehman's laws on mobile apps. In particular, we focused on three laws: the law of continuing change, increasing complexity, and declining quality. We extracted a number of metrics and performed a case study on two applications: VLC and ownCloud. Our findings show that the law of continuing change and declining quality seem to apply for mobile apps, however, we find different outcomes for the law of increasing complexity. Then, we compare the mobile app version to the desktop version and find that the two versions follow the same trends for the law of continuing change. On the contrary, the desktop and mobile version have different trends for the law of increasing complexity and the law of declining quality.
Content may be subject to copyright.
The Evolution of Mobile Apps:
An Exploratory Study
Jack Zhang, Shikhar Sagar, and Emad Shihab
Rochester Institute of Technology
Department of Software Engineering
Rochester, New York, USA, 14623
{jxz8072, fxs1203, emad.shihab}
As mobile apps continue to grow in popularity, it is important to
study their evolution. Lehman’s laws of software evolution have
been proposed and used to study the evolution of traditional, large
software systems (also known as desktop apps). However, do
Lehman’s laws of software evolution hold for mobile apps?, espe-
cially since developing mobile apps presents different challenges
compared to the development of desktop apps.
In this paper, we examine the applicability of three of Lehman’s
laws on mobile apps. In particular, we focused on three laws: the
law of continuing change, increasing complexity, and declining
quality. We extracted a number of metrics and performed a case
study on two applications: VLC and ownCloud. Our findings show
that the law of continuing change and declining quality seem to ap-
ply for mobile apps, however, we find different outcomes for the
law of increasing complexity. Then, we compare the mobile app
version to the desktop version and find that the two versions follow
the same trends for the law of continuing change. On the contrary,
the desktop and mobile version have different trends for the law of
increasing complexity and the law of declining quality.
Categories and Subject Descriptors
H.4 [Information Systems Applications]: Miscellaneous; D.2.8
[Software Engineering]: Metrics—complexity measures
General Terms
Software evolution
Software evolution, mobile software engineering, mobile applica-
The popularity of mobile apps is exponentially growing. These
mobile apps are inherently different than traditional desktop apps.
While previous research has focused on the differences between
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 ’13, August 19, 2013, Saint Petersburg, Russia
Copyright 13 ACM 978-1-4503-2312-3/13/08 ...$15.00.
mobile and desktop apps from a programming point of view, to
the best of our knowledge, there has not been much research that
examines the difference between mobile and desktop apps from an
evolutionary point of view.
In 1974, Lehman and Belady proposed a set of laws pertaining
to software evolution [1]. Lehman’s laws were stated based on em-
pirical observations of commercial software. Much time has passed
since then, but many of Lehman’s laws still apply to this day despite
the evolution of technology in general [2].
With the introduction of smartphones, a new market for software
applications has popped up. These mobile applications are different
from the traditional desktop applications [3]. The development of
these applications is also different. Could the evolution of these
applications be different as well? Do we have to worry about the
increasing complexity of mobile applications? Is it necessary for
mobile applications to continually change in order to survive? Are
mobile applications the special exceptions to these Lehman’s laws?
Much research has been done with Lehman’s laws in terms of
evolution of large desktop applications. Lehman’s laws represent
the dynamics of software development for the lifetime of a piece of
software. However, Lehman’s laws have not been observed in mo-
bile applications. In this paper, we investigate the applicability of
Lehman’s laws of software evolution on mobile apps. In particular,
we focus on following 3 laws:
1. Continuing Change: Software has to continually change if
the software is to remain useful
2. Increasing Complexity: Unless complexity checks are in
place, software will get more complex over releases
3. Declining Quality: As the software evolves, the quality in
software drops
To conduct our study, we use four applications namely - the VLC
desktop application, VLC for Android, the ownCloud desktop ap-
plication, and ownCloud for Android. First, we extracted software
evolution metrics to examine whether Lehman’s laws apply to mo-
bile apps. Second, we compare the evolution metrics for Android
versions of the applications with their Desktop counterparts in or-
der to determine the similarities or differences between the mobile
and desktop apps. In particular, we focus on answering the follow-
ing research questions:
RQ1 Do Lehman’s law of continuing change, increasing complex-
ity, and declining quality apply to mobile apps?
RQ2 Do Lehman’s laws apply to mobile apps and their desktop
version in the same way?
In Section II we review related work. In Section III, we discuss
our case study setup. In Section IV, we present our results. In
Section V, we give an account of our experiences and limitations of
the study. In Section VI, we summarize our work.
A plethora of previous work focused on the evolution of desktop
applications (e.g., [4–6]). However, to the best of our knowledge,
there have not been any studies that examine the applicability of
Lehman’s laws on mobile applications.
One of the initial studies on Evolution in Open Source Software
was performed by Michael Godfrey et al. [6]. First they defined
the difference in the development process for a commercial system
vs. Open Source Software (OSS). Then, they measured the Linux
kernel at the system and subsystem level. They collected Lines of
Code (LOC) for stable and development releases with respect to
time, and found the increase in growth rate of the Linux kernel,
both at system and subsystem level. In our case study, we also use
LOC as one of our primary metrics to measure different aspects of
the software systems.
Yi Wang et al. [7] provided a set of metrics to evaluate the devel-
opment process of OSS. The study considered specific properties
of the open source community and the essential role played by the
members in the evolution of OSS. They conducted a lightweight
case study on the Ubuntu project. Using their metrics they found
the number of modules, number of developers, number of bugs in a
specific moment, number of fixed bugs, and the ratio of fixed bugs
to existing bugs metric useful in assessing the evolution of OSS.
They also analyzed modules which they considered as the atomic
unit in their analysis. But, their metrics model was limited to mod-
ules and was based on Open Source Communities. In this paper,
we considered the number of bugs, number of fixed bugs, and the
ratio of fixed to exisiting bugs metric used in their study to observe
the laws of software evolution in mobile applications.
Businge et al. [8] study software evolution using Lehman’s laws
on plug-ins in Eclipse. They used metrics such as the number of
changes in lines, classes, and dependency metrics to examine the
applicability of Lehman’s laws. Our work complements the prior
work done in the past by examining whether or not mobile apps
follow Lehman’s Laws. The main focus of our paper is to compare
the desktop and mobile versions of the same OSS in order to find
similarities/differences in the evolution patterns in these applica-
3.1 Data Sources
To perform our study, we selected 4 projects: VLC for Android,
the VLC desktop version, ownCloud client for Android, and the
ownCloud desktop client. VLC is a popular media player that is
well known for supporting a wide variety of media formats. Own-
Cloud is a cloud-storage medium similar to Dropbox. The own-
Cloud projects we are examining are actually client software used
to access cloud storage. We extracted the source code and commit
history for these four projects from their Git repositories.
We picked these four projects for the following three reasons:
1. We looked for applications that are different in terms of their
popularity. VLC is a well-known program used by many
users. The development community is also very active, num-
bering in a total of 511 developers altogether working on it.
ownCloud is a less-known application with a small devel-
opment community, numbering in a total of 31 developers
working on it.
2. Another important factor is the amount of data available for
a project. These projects had a development history of at
least 2 years. In addition, most tools that calculate software
metrics (e.g., the Understand metrics tool [9]) only support
certain languages. This becomes problematic when it comes
to examining the Android applications, in particular because
Android applications commonly use a mix of languages like
Java, Javascript, XML, and PHP. The source code for these
four projects has been examined, and we have determined the
languages the projects used could be covered by the Under-
stand metrics tool (the languages being Java, C, C++, XML,
and JavaScript).
3. Third, we selected projects where both the mobile and the
desktop applications were developed by the same company.
During data selection, we have seen a variety of applications
where the the mobile application was a port of the desktop
application developed by a third party. Even though these
other projects are OSS, we felt that the process would be
too different and cause our data to become unreliable. By
enforcing the criteria that mobile and desktop applications
must be developed by the same company, we found only a
few applications that fit the criteria (and had a long enough
commit history).
3.2 Data and Metric Extraction
To examine each of Lehman’s Laws, we defined a set of metrics
to measure the different aspects of software evolution. To calculate
the metrics, we leveraged the repository data for each of the four
applications. In particular, we obtained the commit history of the
different projects from their respective Git repositories. To get the
commit history, we wrote a script that first gets all the unique com-
mit IDs from the project’s Git repository. Then, for each commit
ID, we obtained the full log of that commit and stored it as a text
file. Next, we filter out the commits so that only commits within a
specified date are considered (the exact dates considered for each
project are stated later). Then, we wrote scripts that calculate the
churn, the number of commits, number of bug-fixing commits (i.e.,
commits that contain words associated with a bug fix), and the num-
ber of feature commits (i.e., commits that are not associated with
bug fixing) and the number of hunks (i.e., different parts of a file
touched) in a commit. To calculate the number of hunks, we wrote a
script that uses the built-in diff tool supplied by Git to compare two
different commits. The output of the diff tool was a text file show-
ing the hunks of code that are different. The script would detect
the number of lines that contained the symbols “@@”, where that
particular symbol indicated the beginning of the hunk. By counting
the number of lines that contained the “@@” symbol, we were able
to calculate the number of hunks between two release dates.
3.3 Evolution Metrics Associated to Lehman’s
Lehman’s Law for Continuing Change: A program that is used
in a real-world environment must necessarily change, or else be-
come progressively less useful in that environment. This law states
that the existing software needs to keep changing over time, or else
the software will become obsolete. The continuous change in the
software accounts for feature additions, bugs fixing and platform
changes. To stay in the fast growing business world, it is critical
to provide changes and keep the software bug-free. We used three
metrics to measure this law: code churn, feature commits and num-
ber of hunks.
Table 1: Metric Data based on Dates
Data Point A1 A2 A3 A4 A5 A6 A7 A8
VLC Android Lines of Code 160 5,773 18,085 21,256 199,909 415,882 438,442 467,476
Number of Files 35 57 114 138 818 1,630 1,736 1,816
VLC Desktop Lines of Code 719,413 735,205 767,287 778,393 778,393 788,621 790,864 796,357
Number of Files 56,718 56,793 57,069 57,225 57,224 57,243 56,654 56,663
ownCloud Android Lines of Code 11,345 11,995 16,451 41,484 55,346 56,895 N/A N/A
Number of Files 125 145 181 313 393 450
ownCloud Desktop Lines of Code 3,641 10,984 15,050 20,275 23,064 25,017 N/A N/A
Number of Files 60 117 178 258 287 329
Table 2: Metric Data based on Date Ranges
Data Point A1-A2 A2-A3 A3-A4 A4-A5 A5-A6 A6-A7 A7-A8
VLC Android Code Churn 4,189 26,379 22,197 137,286 114,839 29,524 31,121
Total Commits 92 98 115 266 464 557 330
Feature Commits 15 15 30 44 65 87 45
Bug-Fix Commits 77 83 85 222 399 470 285
Number of Hunks 38 99 130 810 1424 1,003 660
VLC Desktop Code Churn 98,286 466,876 3,417,944 638,691 165,702 169,574 101,667
Total Commits 1,096 1,714 2,023 1,944 1,371 1,515 1,256
Feature Commits 258 401 477 542 376 379 366
Bug-Fix Commits 838 1,313 1,546 1,402 995 1136 890
Number of Hunks 2,697 4,820 14,629 1,9821 3,801 5,443 3,823
ownCloud Android Code Churn 9,967 2,5811 63,900 108,600 42,208 N/A N/A
Total Commits 22 63 265 178 130
Feature Commits 5 10 73 42 36
Bug-Fix Commits 17 53 192 136 94
Number of Hunks 55 82 223 433 551
ownCloud Desktop Code Churn 30,227 28,045 198,180 355,950 108,309 N/A N/A
Total Commits 119 193 215 390 273
Feature Commits 36 45 41 51 35
Bug-Fix Commits 83 148 174 339 238
Number of Hunks 44 82 217 294 555
1. Code Churn: Code Churn is the number of lines added, mod-
ified or deleted in a piece of code. Churn provides the de-
gree to which a given source code file has changed over time.
Code churn can be measured by processing revisions in a ver-
sion control system and counting the total number of lines
changed [10]. We used code churn to look at the changes
made in the software. Presence of code churn refers to the
fact that the software system is continuously changing.
2. Feature Commits: Feature commits is measured as the num-
ber of commits made by each developer to the source code
that add features. To calcualte this metric, we used extract the
total number of commits. Then we determined the bug-fix
commits using keywords ’fix’, ’workaround’, ’crash’, ’bug’,
’error’, ’exception’, ’handle’, and ’handling’. Finally, we
filtered the bug-fix commits from the total number of com-
mits to get the feature commits. The feature commits metric
shows the additions being put into the software system, i.e.,
the software system is continuously changing by adding new
features over time.
3. Number of Hunks: The Git repository has a feature which
uses a diff command to provide a chunk of changed code.
The diff command extracts the number of areas, where the
piece of code was changed between two commits. This is
called a hunk. We extracted the total number of hunks be-
tween two dates.
Lehman’s Law of Increasing Complexity: states that unless work
is done to maintain or reduce complexity, the software will become
more complex as the software evolves. The majority of the prior
work use different code complexity metrics to measure complexity,
however, the majority of the complexity metrics are highly corre-
lated with lines of code and other complexity metrics. Therefore,
we came up with different complexity metrics that are not corre-
lated with each other to help us examine the law of increasing com-
1. Lines of Code: Prior work showed that lines of code is highly
correlated with code complexity metrics. Therefore, we ex-
tracted the total Lines of Code (LOC) and Source Lines of
Code (SLOC).
2. Commits per File: The total number of commits shows the
changes made in the software system. By calculating the av-
erage commits per file, we are able to normalize the number
of commits, since we expect larger files to have more com-
mits. The higher the average number of commits per file, the
more changes are being made at the file level. This metric
serves as an indicator of software complexity.
Lehman’s Law for Declining Quality: states that the quality of
the system appears to decline unless it is rigorously adapted, as
required, to take into account changes in the operational environ-
ment [11]. The law refers to the state of the software system, where
quality is a function of several aspects. It is difficult to empiri-
cally measure the quality of a software system, as it can be relative.
Therefore, to measure declining quality, we use the number of bug
fixing commits.
1. Bug Fix Commits: A piece of software that is low in quality
will be prone to more bugs and defects. Although counter-
intuitive, for this law to hold true, we should see on average
more Bug Fix Commits. If there’s more bug fixes, then there
Figure 1: Code Churn for ownCloud and VLC
are more bugs identified in the system. To detect bug fix
commits, we used a script to search through all the commits
to a project and keep the files that have the following bug
fix keywords: fix, workaround, crash, bug, error, exception,
handle, and handling.
The results of our data collection are shown in Tables 1 and 2.
Table 1 presents the metrics data that can be captured by a single
date, whereas Table 2 presents the metrics data that can only be cap-
tured by date ranges. In order to improve readability, we replaced
dates with data points in the tables. Data point A1 presents the ini-
tial date of 8/19/2011 for both ownCloud applications, and the date
11/15/2010 for both VLC applications. The subsequent data points
were calculated by adding 4 months to the previous data point. So,
A2 is the date four months after A1, and A3 is the date four month
after A2 and so on. In Table 2, we observe the data that could
only be captured in the interval between two dates. No data exists
for ownCloud on data point A7 and A8 because VLC is older than
We have deem the use of data points suitable for two reasons.
First, the time between data points are equivalent (which is a pe-
riod of 4 months). Second, the dates captured for both Android and
Desktop versions of the applications are within 10 days of each
other. For both Android and Desktop in VLC, the dates captured
are exactly the same. For both Android and Desktop in ownCloud,
the dates were on average about 7 days apart. The beginning date
was determined by the initial commit date of the mobile applica-
tions. The subsequent dates were determined by the adding four
months to the previous date. The last data point for all applications
represents the most recent commit date (within 4 months) found in
the source code repository.
After collecting the data for both research questions, we ana-
lyzed each one of the metrics and answered the research questions.
For each law, we plotted graphs between the metrics and the time
interval. For the scatterplot graphs, we also fit a linear line and cal-
culated R2values. The linear line represents the general trend of a
relationship, while the R2values indicate how close the values of
the scatterplot follow the trend. The closer R2is to one, the better
the fit of the scatterplot points to the line.
Do Lehman’s laws apply to mobile apps and their desktop ver-
sion in the same way
RQ1: Do Lehman’s law of continuing change, increasing com-
plexity, and declining quality apply to mobile apps?
To examine the law of continuing change, we looked at the code
churn, feature commits and number of hunks. From Figures 1 , 2
Figure 2: Feature Commits for ownCloud and VLC
Figure 3: No. of Hunks for ownCloud and VLC
Figure 4: LOC for ownCloud and VLC
and 3, we observed the mobile apps are changing constantly over
time. The code is added, deleted or modified regularly, which is
reflected by the code churn value. The fact that code churn exists
mean the system is changing over time. There is also a constant
increase in the feature commits, which implies that new features
were regularly added in the software. The number of hunks are
also increasing over time for both the apps. All the three metrics
provide evidence that the mobile apps do follow Lehman’s law of
continuing change.
For the law of increasing complexity, we used LOC and the av-
erage number of Commits/File metrics. From the Figures 4 and
Figure 5: Commits per File for ownCloud and VLC
Figure 6: Bug Fix Commits for ownCloud and VLC
5, we observe an increase in LOC for both the applications. Al-
though the rate at which the VLC mobile app increases is more than
the ownCloud app, the complexity is increasing over time in both
the mobile applications. But when we closely observed the com-
mits/file 5, we noted a high correlation between the two metrics.
According to figure, we found the average commits/file is decreas-
ing over time for the VLC mobile app, whereas in the ownCloud
app, there was an increase in complexity initially and a decrease
later on. Since the result of the commits/file metrics is different for
the different apps, we can not analyze the complexity of the sys-
tem. However, the increase in LOC implies that the complexity in
the system is increasing over time.
For the law of declining quality, the number of bug-fix com-
mits is used. In Figure 6, the number of bug-fixing commits for
both mobile apps is increasing. The number of bug-fixing commits
shows a constant rate of bug fix commits, there is a steep increase
in both the apps, followed by a sudden decrease. From this metric,
it is challenging to analyze the quality of the app. Based on this
analysis, we observe that perhaps the law of declining quality does
hold for mobile apps. That said, we believe that using more met-
rics and performing this analysis on more apps is needed to have
stronger confidence in out conclusions.
To answer this research question, we compare the evolution met-
rics for both the desktop and mobile apps. First, we examined the
law of continuing change. For code churn, we take the logarithm
of the actual code churn values so we can compare the trends of
the desktop and mobile apps side-by-side (the logarithm was taken
Figure 7: Code Churn for ownCloud over 24 months
Figure 8: Code Churn for VLC over 32 months
since the mobile values were much lower). From Figures 7 and 8,
we observe that the code churn between the mobile and desktop
versions show the same trend, where the number of code churn
rises and falls. We also observe the same kind of trends for the
number of hunks as illustrated in Figures 9 and 10.
But perhaps the more interesting trends to observe are the num-
ber of feature commits. From Figures 11 and 12 we see differ-
ent trends. The mobile version of these graphs show a peak for
the number of feature commits, while the desktop versions show a
stable trend for the number of feature commits introduced at each
date. From these graphs we can conclude that all applications in-
duce change over time, following the law of continuing changes. In
terms of the hunks and churn, the software system even follows the
same trends. At the commit level, however, mobile versions exhibit
more rapid changes when compared to their desktop counterparts.
When examining the law of increasing complexity for mobile
and desktop applications, we observe some differing relationships.
After observing Figures 13 and 14, we can see that the LOC for
both graphs are showing increasing trends. The rates of increase
are different, but they are increasing nonetheless.
RQ2: Do Lehman’s laws apply to mobile apps and their desk-
top version in the same way?
The relationships observed for both mobile and desktop appli-
cations when observing the average number of commits per file
(shown in Figures 15 and 16) are different. For one, the values
are too sporadic to tell us anything. For the law to hold true, we
should see an increasing trend, the idea being the more commits
are made per file, the more complex the system is getting due to
Figure 9: Number of Hunks for VLC over 32 months
Figure 10: Number of Hunks for ownCloud over 24 months
Figure 11: Number of Feature Commits for ownCloud over 24
repeated changes to the system. Instead, we see various spikes.
We believe the fluctuations are caused by the number of files in the
system. The changes in the number of files are not constant trends,
so the randomness of these metrics mixed with the randomness of
the commits themselves will cause great fluctuations in the graph.
Therefore, we cannot conclude whether the mobile and desktop ap-
plications follow the law of increasing complexity.
Instead, we can conclude the development for mobile applica-
tions and the development of desktop applications are different
Figure 12: Number of Feature Commits for VLC over 32
Figure 13: Lines of Code for ownCloud over 24 months
Figure 14: Lines of Code for VLC over 32 months
when measured from a complexity perspective. In LOC, the mo-
bile applications show rapidly increasing trends of LOC while the
desktop versions show a trend towards a constant trend of LOC.
Furthermore, despite the unreliability of Figures 15, and 16, we
can still see the trends for mobile applications differing from the
desktop applications.
Also, for the law of declining quality the mobile applications
and desktop applications show different trends. The bug fix com-
mits in Figures 17 and 18 show fluctuations of increasing and de-
creasing number of bug fixes. We believe this is attributed to the
fact that we considered bug fixing at a commit level. We did not
consider a situation where a single bug-fix commit fixed many bugs.
Figure 15: Commits per File for ownCloud over 24 months
Figure 16: Commits per File for VLC over 32 months
As with the metrics used for the law of increasing complexity,
we cannot conclude as to whether the applications follow the law
of decreasing quality. Regardless, whether these metrics are a good
indicator of declining quality does not change the fact that there
is a difference in the evolution of software quality between mobile
application and desktop applications.
When we initially started our research, we planned to use a num-
ber of complexity metrics to measure the effects of Lehman’s Laws
(which is what the majority of prior work did). These metrics
include Coupling Between Objects, Cyclomatic Complexity, Hal-
stead Difficulty, and Halstead Effort. After doing some correla-
tions, we found that these metrics were highly correlated with one
another in our case study projects. That means the metrics we were
going to apply to all laws would have measured the same thing and
we really only needed one complexity metric. In the end, we de-
cided to use LOC to measure complexity, and discarded all other
metrics that were correlated with LOC.
We also considered a number of process metrics, but a problem
we often ran into were the mobile projects are still too young. For
example, we have considered using the Backlog Management In-
dex (BMI) [12] to measure software quality, which takes into ac-
count the number of closed bugs and total number of bugs identified
in a release. The problem we ran into in this metric relied a lot on a
good quality issue tracker. In most mobile projects we observed, an
issue tracker is not created until half-year to a year after the initial
Figure 17: Bug Fix Commits for ownCloud over 24 months
Figure 18: Bug Fix Commits for VLC over 32 months
commit was made. And even then, people do not really post bugs
until much later. It is hard enough to find a mobile project with a
long history, let alone a mobile project with a mature issue tracker.
One of the more interesting challenges we faced when collect-
ing data was tool replacement. We have ran into many situations
where project owners would switch source code repositories (e.g.,
from SVN to Git) and issue trackers in the middle of development.
Because we had difficulties in accessing old repositories, we were
only able to get the commit history of the most recent years despite
the fact that the project has been around for much longer. Fortu-
nately, for ownCloud and VLC, we collected data for at least 6 data
points (at 4 month intervals), which allowed us to see the relation-
ships between applications as indicated by the graphs.
Selecting the time interval and the date placement was a big is-
sue in this research. The fact is mobile applications are recent. We
could not find a sufficient amount of data right in the middle of a
mobile project, so we had to include the beginning stages of mo-
bile app development to get a sufficient amount of data. We initially
wanted to collect data on release dates only, but the release sched-
ules for mobile applications and desktop were different, one offer-
ing releases every two weeks while the other offered releases on
arbitrary dates. This is why we decided to settle on a time interval
of four months. For the desktop applications, it would seem logical
to capture the first couple of months of development, and then map
those time frames to the time frames of the mobile application de-
velopment. The problem was both the VLC and ownCloud desktop
applications recently migrated their source control to Git. While it
is technically possible to gather the legacy code from that time, it
would have been too difficult and time-consuming to obtain. Sur-
prisingly, despite the data collection for desktop applications start-
ing in the middle of software development, we still see both similar
and different trends in software development.
The software metrics we have chosen seem to be giving us mixed
results. While some of the software metrics (i.e. Lines of Code)
gives us predictable trends, other software metrics (i.e. number of
bug fix commits) gave us trends that we did not expect. A possible
explanation for these unexpected trends is the metrics we have cho-
sen were wrong. In the future, we will look into the validity of the
metrics we have chosen for this research as well as come up with a
more appropriate set of metrics to measure the evolution of mobile
The results of this research gives insights to the applicability
of Lehman’s laws in comparison to mobile applications. For the
law of continuing change, we found remarkably similar trends be-
tween mobile applications and desktop applications. For the law of
increasing complexity, we see through the LOC metric that both
mobile and desktop applications show an increase in complexity,
even if the rate in which the system is getting more complex is
different. Unfortunately, we are not able to conclude whether this
law holds true due to the inaccuracies of our other complexity met-
rics. For the law of declining quality, we found that in terms of
the number of bug fixing commits, the mobile apps also continue
to decline in quality over time (i.e., the number is increasing over
time). That said, we did observe a difference in trends between the
desktop and mobile versions of the app. In our future work, we
plan to focus our energies into selecting more appropriate metrics
to re-observe these laws.
Our greatest findings in this research are the relationships in the
evolution of mobile software applications and their desktop coun-
terparts. If we are strictly to look at the evolution of the lines of
code, and the lines of code that has changed, then we will see the
same trends in development. If we were to look at evolution using
process level metrics, we found that the development of the pro-
gram exhibited different trends. For the next steps, we would like
to see why these differences exist despite the similar evolution in
structure to gain a deeper understanding of software evolution in
[1] M. Lehman, “Programs, life cycles, and laws of software
evolution,Proceedings of the IEEE, vol. 68, no. 9, pp.
1060–1076, 1980.
[2] G. Xie, J. Chen, and I. Neamtiu, “Towards a better
understanding of software evolution: An empirical study on
open source software,” in Software Maintenance, 2009.
ICSM 2009. IEEE International Conference on. IEEE,
2009, pp. 51–60.
[3] R. Minelli and M. Lanza, “Software analytics for mobile
applications–insights and lessons learned,” 2011 15th
European Conference on Software Maintenance and
Reengineering, vol. 0, pp. 144–153, 2013.
[4] K. Johari and A. Kaur, “Effect of software evolution on
software metrics: an open source case study,SIGSOFT
Softw. Eng. Notes, vol. 36, no. 5, pp. 1–8, Sep. 2011.
[Online]. Available:
[5] G. Singh and H. Singh, “Effect of software evolution on
metrics and applicability of lehman’s laws of software
evolution,SIGSOFT Softw. Eng. Notes, vol. 38, no. 1, pp.
1–7, Jan. 2013. [Online]. Available:
[6] M. W. Godfrey and Q. Tu, “Evolution in open source
software: A case study,” in Software Maintenance, 2000.
Proceedings. International Conference on. IEEE, 2000, pp.
[7] Y. Wang, D. Guo, and H. Shi, “Measuring the evolution of
open source software systems with their communities,”
SIGSOFT Softw. Eng. Notes, vol. 32, no. 6, Nov. 2007.
[Online]. Available:
[8] J. Businge, A. Serebrenik, and M. van den Brand, “An
empirical study of the evolution of eclipse third-party
plug-ins,” in Proceedings of the Joint ERCIM Workshop on
Software Evolution (EVOL) and International Workshop on
Principles of Software Evolution (IWPSE). ACM, 2010, pp.
[9] SciTools, “Understand: Source code analysis and metrics,”, June, 2013.
[10] A. Meneely and O. Williams, “Interactive churn metrics:
socio-technical variants of code churn,ACM SIGSOFT
Software Engineering Notes, vol. 37, no. 6, pp. 1–6, 2012.
[11] D. Coleman, D. Ash, B. Lowther, and P. Oman, “Using
metrics to evaluate software system maintainability,”
Computer, vol. 27, no. 8, pp. 44–49, Aug. 1994. [Online].
[12] L. Grammel, H. Schackmann, and H. Lichter,
“Bugzillametrics: an adaptable tool for evaluating metric
specifications on change requests,” in Ninth international
workshop on Principles of software evolution: in conjunction
with the 6th ESEC/FSE joint meeting, ser. IWPSE ’07.
New York, NY, USA: ACM, 2007, pp. 35–38. [Online].
[13] S. Apel, O. Lessenich, and C. Lengauer, “Structured merge
with auto-tuning: balancing precision and performance,” in
Proceedings of the 27th IEEE/ACM International Conference
on Automated Software Engineering, ser. ASE 2012. New
York, NY, USA: ACM, 2012, pp. 120–129. [Online].
[14] R. Sindhgatta, N. C. Narendra, and B. Sengupta, “Software
evolution in agile development: a case study,” in Proceedings
of the ACM international conference companion on Object
oriented programming systems languages and applications
companion, ser. SPLASH ’10. New York, NY, USA: ACM,
2010, pp. 105–114. [Online]. Available:
[15] Owncloud source code repository. [Online]. Available:
[16] Vlc source code repository. [Online]. Available:
... To better understand the evolution of mobile applications and find patterns in their evolution process, Zhang, Sagar, and Shihab [289] examined the applicability of three of Lehman's [152,153] laws on mobile apps: continuing change, increasing complexity and declining quality. The law of continuing change says that systems must be continually adapted else they become progressively less satisfactory. ...
... Moreover, they found that the desktop and mobile versions have different trends for the law of increasing complexity and the law of declining quality. Like Zhang, Sagar, and Shihab [289], Li et al. [158] conducted an empirical study focused on Lehman's laws. The authors examined long spans in the lifetime of 8 typical open-source mobile applications, covering 348 official releases, and several metrics were extracted to capture the characteristics of mobile applications. ...
In recent years, with more than 3 million applications on its official store, Google’s Android has dominated the market of mobile operating systems worldwide. Despite this success, Google has continued evolving its operating system and its toolkits to ease application development. In 2017 Google declared Kotlin as an official Android programming language. More recently, during the Google I/O 2019, Google announced that Android became ‘Kotlin-first’, which means that new API, libraries, and documentation will target Kotlin and eventually Java and Kotlin as preferred language to create new Android applications. Kotlin is a programming language that runs on the Java Virtual Machine (JVM) and it is fully interoperable with Java because both languages are compiled to JVM bytecode. Due to this characteristic, Android developers do not need to migrate their existing applications to Kotlin to start using Kotlin in these applications. Moreover, Kotlin provides a different approach to write applications because it combines object-oriented and functional features. Therefore, we hypothesize that the adoption of Kotlin by developers may affect different aspects of Android applications’ development. However, one year after this first announcement, there were no studies in the literature about Kotlin. In this thesis, we conducted a series of empirical studies to address these lacks and build a better understanding of creating high-quality Android applications using Kotlin. First, we carried a study to measure the degree of adoption of Kotlin. Our results showed that 11% of the studied Android applications had adopted Kotlin. Then, we analyzed how the adoption of Kotlin impacted the quality of Android applications in terms of code smells. We found that the introduction of Kotlin in Android applications initially written in Java produces a rise in the quality scores from 50% to 80% according to the code smell considered. We analyzed the evolution of usage of features introduced by Kotlin, such as Smart cast, and how the amount of Kotlin code changes over applications’ evolution. We found that the number of instances of features tends to grow throughout applications’ evolution. Finally, we focused on the migration of Android applications from Java to Kotlin. We found that 25% of the open source applications that were initially written in Java have entirely migrated to Kotlin, and for 19%, the migration was done gradually, throughout several versions, thanks to the interoperability between Java and Kotlin. This migration activity is challenging because: a) each migrated piece of code must be exhaustively tested after the migration to ensure it preserves the expected behavior; b) a project can be large, composed of several candidate files to be migrated. In this thesis, we present an approach to support migration, which suggests, given a version of an application written in Java and eventually, in Kotlin, the most convenient files to migrate. We evaluated our approach’s feasibility by applying two different machine learning techniques: classification and learning-to-rank. Our results showed that both techniques modestly outperform random approaches. Nevertheless, our approach is the first that proposes the use of machine learning to recommend file-level migrations. Therefore, our results define a baseline for future work. Since the migration from Java to Kotlin may positively impact the application’s maintenance and that migration is time-consuming and challenging, developers may use our approach to select the files to be migrated first. Finally, we discuss several research perspectives opened by our results that can improve the experience of creating high-quality Android applications using Kotlin.
... Negative Urgency had the same indirect effect with problematic mobile phone use. Given these results, the interpretation would be the same and it would only be added that this device, in addition to social media, offers a variety of applications such as music, online games, video, etc., with greater use and access to other apps (47). ...
... This pattern of behavior is constantly reinforced through rewards, promotes compulsive use, and negatively affects the subject. Mobile phones have functions beyond being an access point to social media (47), but, given the difficulty of expressing emotions in a person, or having limited face-to-face interactions, it is very likely that gradually, the acceptance found within social media, the satisfaction of using it, and the positive experiences associated to it can lead to a problematic use (52,53). ...
The number of social media and mobile phone users is constantly increasing. Researchers worldwide argue that studying the problematic use of these technologies is of the utmost importance to develop better interventions in the future. The study proposes a predictive model of problematic use of social media and mobile phones in relation to social anxiety the components of impulsivity and emotional regulation. A non-experimental, predictive, and correlational cross-sectional design was used to investigate the interaction between psychological variables. Through a convenience sampling, 242 university students aged 18 to 24 were selected (mean age = 20.29 SE = 2.19) to interact with relevant instruments. Then was applied the predictive model using the structural equations’ method and obtained a final predictive model with the following results: χ2 = 7.6, gl = 7, P <0.001, χ2 / df = 1.08, NFI = 0.96, CFI = 0.99, RMSEA = 0.019, IC 90 = [0.001 - 0.08], SRMR = 0.038. The findings of direct and indirect effects related to problematic use of mobile phones, social media, and hours invested, link these and the following variables: Negative Urgency, Expressive Suppression of emotions, and Social Anxiety. Keywords: Problematic use, impulsivity, social anxiety, emotional regulation, social media, mobile phone.
... Exposure to new method of E-commerce and M-commerce transactions and information overload bring increased uncertainty for both new and experienced internet users (Kailani & Kumar, 2011), including traditional businesses as the business owners struggle to understand the advantages, benefits, risks, and challenges posed by the adoption of "E" or M-commerce. This is because customers today do not shop the way they did a decade ago, and previously, apps (applications), more commonly known as programs, were for computers only (Zhang, Sagar, & Shihab, 2013). ...
... a manner not previously experiences, whereby these mobile application platforms have now become a new medium of expression allowing users to engage and maintain real relationship constantly (Ellison, Steinfeld, & Lampe, 2007;Kwo & Wen, 2010;Powell, 2009). These mobile apps are inherently different than traditional desktop applications or programs (Zhang et. al., 2013), and thus, more conservative businesses are still hesitant in adopting and applying mobile applications (mobile apps) into the businesses. The hesitation is due to the fact that there have been few researches that focused on exploring the frequency and extent of mobile apps utilization amongst smartphone or tab or iPad users for various ...
Full-text available
Conference Paper
The rise of the internet and Mobile Commerce (M-Commerce) has certainly changed the way businesses and organizations market their products and services or reach out to customers in today's globalized world. However, many companies are still uncertain about the extent of M-Commerce adoption amongst Internet users and thus, deemed it too risky to develop mobile applications to enhance their businesses. Therefore, the focus of this study is to ascertain the extent of mobile applications adoptions by the Generation Y users within Penang, Malaysia in order to provide an insight to businesses as to the potential of M-Commerce for the younger, upcoming generation of Internet users. The purpose of choosing the Gen Y as the sample population is because the Gen Ys are born into the Internet age and are usually the early adopters of new digitalized technologies. Therein lies the strength of this research as it will contribute to the literature within a Malaysian context, while simultaneously providing an understanding for the M-Commerce industry to build up the required confidence to invest in M-Commerce applications (Mobile Apps). The findings indicated that Gen Ys are more likely to download mobile applications that are linked to entertainment vis-à-vis educational applications or other online purchases mobile applications. Nevertheless, gender does not play a part in the adoption of mobile applications as compared to other online purchases as found in the study. However, when the mobile app is provided for free, Gen Y users are more likely to download the specific apps. Apart from the above, the electronic word-of-mouth (E-WOM) was found to be significant in contributing to the adoption of specific mobile applications, thereby indicating that businesses need to consider the impact of E-WOM in attracting more traffic unto their sites via mobile applications.
... The ever increasing complexity of mobile applications, given by their peculiarities (e.g., ensuring that the application is downloadable, works seamlessly, and gives the same experience across various devices and users) as well as by their differences with respect to standard applications (Wasserman 2010;Zhang et al. 2013), has pushed the research community to define methods to support developers with testing activities (Muccini et al. 2012). Researchers have been investigating how developers test their mobile applications in comparison to standard systems (Muccini et al. 2012), showing dissimilarities, peculiarity and possible effective practices. ...
Full-text available
These days, over three billion users rely on mobile applications (a.k.a. apps) on a daily basis to access high-speed connectivity and all kinds of services it enables, from social to emergency needs. Having high-quality apps is therefore a vital requirement for developers to keep staying on the market and acquire new users. For this reason, the research community has been devising automated strategies to better test these applications. Despite the effort spent so far, most developers write their test cases manually without the adoption of any tool. Nevertheless, we still observe a lack of knowledge on the quality of these manually written tests: an enhanced understanding of this aspect may provide evidence-based findings on the current status of testing in the wild and point out future research directions to better support the daily activities of mobile developers. We perform a large-scale empirical study targeting 1,693 open-source Android apps and aiming at assessing (1) the extent to which these apps are actually tested, (2) how well-designed are the available tests, (3) what is their effectiveness, and (4) how well manual tests can reduce the risk of having defects in production code. In addition, we conduct a focus group with 5 Android testing experts to discuss the findings achieved and gather insights into the next research avenues to undertake. The key results of our study show Android apps are poorly tested and the available tests have low (i) design quality, (ii) effectiveness, and (iii) ability to find defects in production code. Among the various suggestions, testing experts report the need for improved mechanisms to locate potential defects and deal with the complexity of creating tests that effectively exercise the production code.
... . This metric computes the change frequency of an artifact using CHO and is represented as a percentage to normalize it. The metric was described and used in previous studies 27,28 and is basically the FRCH metric defined by Elish and Al-Khiaty 26 but normalized as a percentage. where v is the commit for which CHO is computed and [a, b] is the interval of commit indexes considered. ...
Full-text available
Although architectural smells are one of the most studied type of architectural technical debt, their impact on maintenance effort has not been thoroughly investigated. Studying this impact would help to understand how much technical debt interest is being paid due to the existence of architecture smells and how this interest can be calculated. This work is a first attempt to address this issue by investigating the relation between architecture smells and source code changes. Specifically, we study whether the frequency and size of changes are correlated with the presence of a selected set of architectural smells. We detect architectural smells using the Arcan tool, which detects architectural smells by building a dependency graph of the system analyzed and then looking for the typical structures of the architectural smells. The findings, based on a case study of 31 open-source Java systems, show that 87% of the analyzed commits present more changes in artifacts with at least one smell, and the likelihood of changing increases with the number of smells. Moreover, there is also evidence to confirm that change frequency increases after the introduction of a smell and that the size of changes is also larger in smelly artifacts. These findings hold true especially in Medium–Large and Large artifacts.
Full-text available
Conference Paper
Mobile applications, known as apps, are software systems running on handheld devices, such as smartphones and tablet PCs. The market of apps has rapidly expanded in the past few years into a multi-billion dollar business. Being a new phenomenon, it is unclear whether approaches to maintain and comprehend traditional software systems can be ported to the context of apps. We present a novel approach to comprehend apps from a structural and historical perspective, leveraging three factors for the analysis: source code, usage of third-party APIs, and historical data. We implemented our approach in a web-based software analytics platform named SAMOA. We detail our approach and the supporting tool, and present a number of findings obtained while investigating a corpus of mobile applications. Our findings reveal that apps differ significantly from traditional software systems in a number of ways, which calls for the development of novel approaches to maintain and comprehend them.
Full-text available
Since the inception of Lehman's software evolution laws in the early 1970s, they have attracted significant attention from the research community. However, to our knowledge, no study of applicability of these laws on the software systems that exhibit constrained evolution process has been carried out so far. In this paper we take a first step in this direction and investigate the constrained evolution of 21 Eclipse third-party plug-ins. We investigate the trends followed by the plug-ins dependencies on Eclipse over time. The study spans 6 years of the evolution of Eclipse evolving from release 3.0 to release 3.5. Our findings confirm the laws of continuing change, self regulation and continuing growth when metrics related to dependencies between the plug-ins and the Eclipse Architecture are considered. Unlike this, the conservation of familiarity law was not confirmed and the results for the declining quality law were inconclusive.
Full-text available
Conference Paper
The agile development method (ADM) is characterized by continuous feedback and change, and a software system developed using ADMevolves continuously through short iterations. Empirical studies on evolution of software following agile development method have been sparse. Most studies on software evolution have been performed on systems built using traditional (waterfall) development methods or using the open source development approach. This paper summarizes our study on the evolution of an enterprise software system following ADM. We evaluated key characteristics of evolution in the light of Lehman's laws of software evolution dealing with continuous change and growth, self-regulation and conservation, increasing complexity and declining quality. Our study indicates that most laws of evolution are followed by the system. We also present our observations on agile practices such as collective code ownership, test driven development and collaboration when the team is distributed.
Full-text available
Conference Paper
To manage the evolution of software processes and products, it is essential to evaluate their current state and how it evolved. This information can be obtained by analyzing the data available in change request management (CRM) systems like Bugzilla. Metrics and charts on change requests are already available in current CRM systems. They provide information about common metrics, but their adaptability is limited. This paper describes a more flexible approach for the evaluation of metrics on change requests. The main characteristics of the tool presented in this paper are the separation between metric specification and data retrieval, an event driven algorithm that calculates time series data, and an abstraction of its data sources.
Full-text available
Conference Paper
Since the inception of Lehman's software evolution laws in the early 1970s, they have attracted significant attention from the research community. However, to our knowledge, no study of applicability of these laws on the software systems that exhibit constrained evolution process has been carried out so far. In this paper we take a first step in this direction and investigate the constrained evolution of 21 Eclipse third-party plug-ins. We investigate the trends followed by the plug-ins dependencies on Eclipse over time. The study spans 6 years of the evolution of Eclipse evolving from release 3.0 to release 3.5. Our findings confirm the laws of continuing change, self regulation and continuing growth when metrics related to dependencies between the plug-ins and the Eclipse Architecture are considered. Unlike this, the conservation of familiarity law was not confirmed and the results for the declining quality law were inconclusive.
A central part of software quality is finding bugs. One method of finding bugs is by measuring important aspects of the software product and the development process. In recent history, researchers have discovered evidence of a "code churn" effect whereby the degree to which a given source code file has changed over time is correlated with faults and vulnerabilities. Computing the code churn metric comes from counting source code differences in version control repositories. However, code churn does not take into account a critical factor of any software development team: the human factor, specifically who is making the changes. In this paper, we introduce a new class of human-centered metrics, "interactive churn metrics" as variants of code churn. Using the git blame tool, we identify the most recent developer who changed a given line of code in a file prior to a given revision. Then, for each line changed in a given revision, determined if the revision author was changing his or her own code ("self churn"), or the author was changing code last modified by somebody else ("interactive churn"). We derive and present several metrics from this concept. Finally, we conducted an empirical analysis of these metrics on the PHP programming language and its post-release vulnerabilities. We found that our interactive churn metrics are statistically correlated with post-release vulnerabilities and only weakly correlated with code churn metrics and source lines of code. The results indicate that interactive churn metrics are associated with software quality and are different from the code churn and source lines of code.
Conference Paper
Software-merging techniques face the challenge of finding a balance between precision and performance. In practice, developers use unstructured-merge (i.e., line-based) tools, which are fast but imprecise. In academia, many approaches incorporate information on the structure of the artifacts being merged. While this increases precision in conflict detection and resolution, it can induce severe performance penalties. Striving for a proper balance between precision and performance, we propose a structured-merge approach with auto-tuning. In a nutshell, we tune the merge process on-line by switching between unstructured and structured merge, depending on the presence of conflicts. We implemented a corresponding merge tool for Java, called JDime. Our experiments with 8 real-world Java projects, involving 72 merge scenarios with over 17 million lines of code, demonstrate that our approach indeed hits a sweet spot: While largely maintaining a precision that is superior to the one of unstructured merge, structured merge with auto-tuning is up to 12 times faster than purely structured merge, 5 times on average.
Conference Paper
Software evolution is a fact of life. Over the past thirty years, researchers have proposed hypotheses on how soft- ware changes, and provided evidence that both supports and refutes these hypotheses. To paint a clearer image of the software evolution process, we performed an empirical study on long spans in the lifetime of seven open source projects. Our analysis covers 653 official releases, and a combined 69 years of evolution. We first tried to verify Lehman's laws of software evolution. Our findings indicate that several of these laws are confirmed, while the rest can be either confirmed or infirmed depending on the laws' op- erational definitions. Second, we analyze the growth rate for projects' development and maintenance branches, and the distribution of software changes. We find similarities in the evolution patterns of the programs we studied, which brings us closer to constructing rigorous models for soft- ware evolution.
Open Source Software (OSS) has become the subject of much commercial and academic interest in last few years. As traditional software, OSS also evolves to fulfill the need of stakeholders. Therefore, providing quantitative metrics for OSS evolution has also become an urgent issue. However, most existing studies of software evolution have been performed on systems developed within a single company using traditional management techniques. These metrics models are inadequate to measure OSS evolution. In this paper, we describe a preliminary evolution metrics set for evaluating OSS. The most significant novelty of this model is that it takes specific properties of Open Source Community (OSC) into consideration. In another word, we measure the evolution of OSS and OSC together. We also provide a lightweight case study on Ubuntu project using this metrics set. We find out that the Open Source Community and its members also play essential role in OSS evolution. We expect this metrics model can bring better understandings and explanations of phenomena in open source development and evolution.