An Exploratory Study on the Occurrence of Self-Admitted Technical Debt in Android Apps

An Exploratory Study on the Occurrence of
Self-Admitted Technical Debt in Android Apps
Gregory Wilder II, Riley Miyamoto, Samuel Watson, Rick Kazman, Anthony Peruma

Overview
We explore the occurrence and characteristics
of self-admitted technical debt in 15,614 open-
source Android apps

Introduction
• The popularity of mobile devices has led to the development of
numerous Android apps
• Over 2 million as of September 2022 on Google Play
• Like non-mobile systems, mobile apps are also subject to poor code
quality
• Poor code quality can result from lack of documentation, partial or missing
functionality, lack of testing, and even workarounds
• Technical debt is the phenomenon of developers knowingly
compromising code and design quality in favor of meeting project
deadlines/milestones
• Which can result in increased maintenance costs and an increased risk of project
failure

Self-Admitted Technical Debt (SATD)
• SATD refers to instances where developers consciously
acknowledge the presence of technical debt in their system
through documentation
• Prior research has used SATD to study implementation
compromises in open-source and industrial software across
various domains and programming languages
• There is a lack of research on its occurrence in mobile apps,
specifically Android apps
• Mobile apps have unique constraints such as being highly user-
centric, supporting various portable devices, and being limited in
size, functionality, security, and resource/energy consumption.

Example of mobile specific tech debt
Workaround to turn off
the camera flash for
different mobile devices
(i.e., Samsung Galaxy
and Samsung Behold II).

Related Work on Android TechDebt
• Approaches are proposed to identify and measure technical
debt:
• identifying architectural debt through a reference architecture
• identifying energy debt through code smells
• identifying accessibility debt through developer interviews
• Refactoring based tools:
• addressing technical debt related to state feature flags
• SonarQube-based tool to detect energy debt
• Empirical study showing that mobile code smells represent
inadvertent technical debt (i.e., debt introduced by oversight
than strategically)

Goal & Impact
Discover the extent to which Android
apps incur SATD and form a high-level
understanding of the types and causes
of these sub-optimal implementations
Facilitate helping app developers in
understanding and planning for areas in their
apps that are prone to incurring debt; support
the development of tools and techniques

Research Questions
• RQ1: To what extent do open-source Android app developers
document technical debt in the code?
• Understand the volume of SATD typically contained in Android apps
• RQ2: What are the specific types of self-admitted technical debt
occurring in open-source Android apps?
• Categorize the discovered SATD into one of seven predefined categories
• RQ3: What code elements in Android apps are susceptible to
technical debt?
• Provides insight into areas of concern that Android app developers can
focus on during the implementation and maintenance of apps

Contributions
A publicly available dataset of
SATD comments in Android apps
for replication or extension studies
An understanding of technical debt
in Android apps and a discussion
on avenues for future research

Experiment Design
Source Dataset: Used in prior research studies; we cloned 37,342 Android app project repositories
Parse & Analyze Source Files:
• 1,386,942 Java files detected; each project contains a median of 10 Java files
• Using an AST, we detected 14,383,880 comments; only 35,982 projects contained comments
• Utilized SATD Detector Core to detect SATD-related comments; used in prior research studies
• Utilize cloc to count lines of code
RQ Analysis
• Quantitative and qualitative data analysis
• N-Gram generation and analysis of SATD comments

RQ 1: To what extent do open-source Android app
developers document technical debt in the code?
• Our dataset contains 451,499 SATD-related comments
• Most apps (about 67%) have between 1 to 5 SATD comments, with a
median of 2 SATD files per app
• SATD contribute to, on average, 5.97% of an app’s comments
• Files with SATD have a significantly higher median number of lines of
code compared to files without SATD

RQ 2: What are the specific types of self-admitted
technical debt occurring in open-source Android apps?
• Grouping SATD comments into seven predefined tech debt categories
(Code, Design, Requirement, Defect, Documentation, Test, Unclassifiable)
• Manually reviewed and annotated a random, statistically significant sample of 386
SATD comments (95% confidence level and a 5% confidence interval)
• Code - documentation of workarounds implemented
by developers to achieve a specific goal
• Workarounds to fix a bug:
• “Also workaround for bug on Nexus 6...”
• Need to update identifiers:
• “TODO: Rename parameter arguments…”
• “TODO: Use strings for id’s too”

RQ 2: Cont.…
• Design - shortcomings in the app's
structure or design (e.g., move code,
apply object-oriented principles such
as encapsulation and abstraction)
• “TODO move this out to its own class”
• “That’s a larger refactoring we’ll save for another
day”)
• “TODO:CentralSurfaces should be encapsulated
behind a Controller”
• Requirement - documentation of
functionality that is not yet
implemented or incomplete
• Business logic: ‘‘TODO Add more comparision
later”
• Handle other versions of the operating system:
“TODO: We’ll have that on Android 2.2”
• Defect - documentation of known
defects (functional, non-functional &
generic defects)
• “too high, fix height”
• “FIXME, this is wrong”
• Documentation - comments as
reminders to explain the behavior of
code in the future
• “TODO: document”
• Test - documenting the need to
create/run tests for the implemented
functionality
• “TODO: Work on the test tmr”
• Unclassifiable - incomplete or vague
• “TODO it’s bad”

RQ 3: What code elements in Android apps are
susceptible to technical debt?
Manual examination of top 50 unigrams, bigrams, and trigrams
Group related n-grams into categories -- Four high-level categories— Android SDK API, General UI, General
Programming, and Hardware.
• Android SDK API - documenting sub-optimal code related to using Android-
specific features, such as UI-related APIs/components and non-UI-specific APIs
• Android UI API - we encounter terms such as ‘Activity’, ‘View’, ‘Fragment’, ‘Listener’,
‘ActionBar’,and ‘BoundingBox’
• “TODO:use dialog fragment”
• “TODO Add a View to the layout with awidth of match parent and a height of 1dp”
• Android non-UI API – frequent terms include ‘Context’, ‘Loader’, ‘Content-Provider’, and
‘AndroidManifest’, ‘deprecated api’ and ‘api level’
• “TODO: Set up a content provider interface…”
• “TODO: use API level 24 or above to correct this”
• General UI - implementing new or missing functionality related to the apps’ user
interface (e.g., color, margin, position, button, etc.)
• “TODO: Add support for border color and types”

RQ 3: Cont.…
• General Programming – we encounter terms related to general
programming concepts or activities
• refactoring, date/time, storage, security, error handling, external
resources
• “TODO: Rename and change types and number of parameters”
• “TODO: database operations should be done on separate thread”
• “TODO: what if this throws an exception?”
• Hardware - code workarounds that integrates with specific
mobile device components (e.g., camera) or support specific
devices
• “TODO : add usb device attached intent”

Overall Findings
Android app developers make sub-optimal decisions when building their apps
(similar to non-mobile system developers)
• The occurrence of SATD comments in Android apps is comparatively low
• Android: 5.97% of comments are SATD; Non-mobile: 15% - 22% of comments are SATD
• The smaller size of Android apps and the fact that they are often developed by small teams
may contribute to the lower occurrence of SATD comments.
• Similar to non-mobile systems, mobile apps are more prone to code debt
• Low occurrence of requirements debt might be due to apps having limited functionality than non-mobile systems
• Low test debt can be an indicator of insufficient test cases
• The Android UI specific features (e.g., Activities, Fragments, and Listeners) associated with
SATD are known to be associated with presentation layer code smells
• Security related SATD associated with permissions and data leakage also align with prior work

Key Takeaways
• Integration of technical debt detection tools into the developer workflow
• Educate developers about the availability of detection tools
• Developers can integrate these tools into their build process to receive notifications when code is
committed
• Opportunity for IDE vendors and plugin developers
• Expand research into mobile technical debt
• This study found specific Android APIs that are usually associated with technical debt, which can
help the community build or enhance code quality tools to support mobile app developers
• Opportunity to conduct similar studies on iOS apps
• Expand techniques and tools to refactor mobile app technical debt
• Opportunity to develop refactoring operations geared towards mobile app code, particularly
UI/presentation layer code
• Complement tool use with code reviews
• The review process can catch instances of poorly composed SATD comments, such as vague or
incomplete comments

Conclusion & Future Work
• Mobile apps are subject to poor programming practices, similar to non-
mobile systems
• The ease of app development does not necessarily mean high-quality and
maintenance friendly apps
• We conducted a large-scale empirical study on open-source Android apps
• Android apps are not exempt from technical debt, but the volume of SADT they
exhibit is lower than non-mobile systems
• Most debt falls under the Code debt category, of which most are implementation of
workarounds
• We identified shortcomings developers take when implementing code that utilizes
Android APIs
• Future work: examining the repayment and survival of SADT in Android
apps, by analyzing the version history of source files

Thank You!
Anthony Peruma
https://www.peruma.me

An Exploratory Study on the Occurrence of Self-Admitted Technical Debt in Android Apps

Recommended

More Related Content

Similar to An Exploratory Study on the Occurrence of Self-Admitted Technical Debt in Android Apps (20)

More from University of Hawai‘i at Mānoa (20)

Recently uploaded (20)

An Exploratory Study on the Occurrence of Self-Admitted Technical Debt in Android Apps