Trash Code and Mess in Mobile Projects — Signs and Refactoring

What Is Trash Code in Development

Trash code (also spaghetti code, mess, big ball of mud) is a metaphor for a codebase that has lost its structure and turned into a tangled web of dependencies. In such code, any change in one place breaks another, and adding new functionality becomes a risky quest.

In mobile development, trash code is especially critical: an app built on a “mess” starts to lag, crash on older devices, and struggles to pass code review. An iOS project without architecture may fail App Review due to instability.

According to Stripe, developers spend up to 42% of their work time reading and understanding existing code. In projects with trash code, this figure exceeds 60%, making development extremely inefficient.

Origin of the Terms

Spaghetti code is the oldest term, dating back to the 1970s. It describes code with chaotic control flow, resembling tangled pasta.

Big ball of mud is a term introduced by Brian Foote and Joseph Yoder in 1997 to describe systems without a clear architecture that grow chaotically.

Why Trash Code Is Dangerous for Business

Trash code slows down the release of new features to market. The team spends time not on creating value, but on trying to understand how the existing code works and how not to break anything.

According to McKinsey, companies with low code quality spend 20–40% more on product maintenance, and their speed of shipping new features is 2–3 times lower compared to companies with high code quality.

Signs of Trash Code and How to Recognize It

Recognizing trash code can be done through a set of objective indicators, some of which are measured automatically. The more indicators match, the more serious the problem.

In the industry, code quality metrics such as Halstead Complexity, Maintainability Index, and Technical Debt Ratio are used. Understanding these metrics helps objectively assess the state of a codebase.

Copy-Paste (Code Duplication)

The most common sign of trash code is repeated code blocks. Instead of extracting a common function, developers copy code from one place to another with minimal changes.

A duplication level of up to 5% is considered normal. If duplication exceeds 15%, it is a serious warning. Tools like Simian and PMD Copy Paste Detector help identify copy-paste automatically.

Long Methods and Classes

A method longer than 100 lines is a clear sign of trash code. Such a method usually does too much and violates the Single Responsibility Principle.

Classes with more than 1000 lines of code are also problematic. They contain unrelated functionality, making testing, understanding, and modifying the code difficult.

High Cyclomatic Complexity

Cyclomatic complexity by McCabe is a metric that shows the number of independent paths in code. A value above 15 is considered problematic.

Methods with a complexity above 30 are in the “disaster zone.” They contain too many branches, making them impossible to test and understand without deep analysis.

Causes of Trash Code

Trash code does not appear “on its own” — it is always the result of certain processes and decisions in the team. Understanding the causes helps prevent it in the future.

According to JetBrains Developer Ecosystem 2024, 67% of developers admit they write worse code than they could due to lack of time. This is the main reason for accumulating technical debt.

Rush and Deadlines

The most common cause is tight deadlines. The team writes code “however it turns out,” just to meet the deadline. Refactoring, tests, and code review are put off “for later.”

The problem is that “later” never comes — new deadlines appear in the next sprint, and technical debt piles up like a snowball.

Lack of Code Review

Without code review, each developer writes in their own style, uses their own patterns, and leaves their own “markers.” Over time, the codebase loses consistency.

Teams that practice mandatory code review for every pull request have 60% fewer defects in production, according to a 2024 SmartBear study.

Weak Architecture from the Start

If a project starts without a clear architecture, trash code is inevitable. The first “quick fixes” lay a foundation on which it is hard to build something quality later.

In mobile development, the choice of architecture (MVC, MVP, MVVM, Clean Architecture) should be a conscious decision made before writing code, not a result of evolution.

Methods to Fight Trash Code

Fighting trash code requires a systematic approach and discipline from the entire team. There is no single tool or practice that will solve the problem — a set of measures is needed.

The main principle is to prevent trash code at the writing stage, not fix it afterward. Prevention is always cheaper than refactoring an existing “mess.”

Coding Standards

A unified code style is the foundation for preventing trash code. Coding standards (Code Style) should be documented and automatically checked by linters.

For iOS, SwiftLint is used; for Android, Ktlint and Detekt. Configuring rules in a configuration file allows automatically rejecting pull requests that violate standards.

Regular Refactoring

Refactoring is not about fixing bugs, but improving code structure without changing its behavior. It should be a regular part of the development process, not a separate project.

It is recommended to allocate 20% of each sprint’s time to refactoring and paying off technical debt. This prevents the accumulation of “mess” and maintains team speed in the long term.

Mandatory Code Review

Every pull request should be reviewed by at least one developer. Code review identifies not only bugs but also architecture violations, style issues, and potential sources of trash code.

A good practice is a code review checklist that includes checking for copy-paste, method length, cyclomatic complexity, and test coverage. Without a checklist, reviewers miss up to 50% of problems.

Tools for Cleaning Up a Codebase

Modern code analysis tools allow automatically detecting trash code, measuring technical debt, and monitoring quality. Integrating these tools into the CI/CD pipeline provides continuous monitoring.

It is recommended to use at least one static analyzer and one metric measurement tool. Additionally, a platform for aggregating code quality data can be connected.

Static Analyzers

• SonarQube — the leading code quality analysis platform, supports 30+ languages and provides Technical Debt Ratio metrics
• ESLint — the standard for JavaScript and TypeScript, configurable via configuration files and integrated into IDEs
• SwiftLint — a mandatory tool for iOS projects, checks compliance with the Swift Style Guide

According to SonarSource, teams using static analysis reduce the number of production bugs by 30% within the first quarter after adoption.

Metric Measurement Tools

CodeClimate and Codacy are platforms that aggregate code quality metrics, track trends, and highlight “hot spots” — files with the highest technical debt.

For Android projects, Detekt provides over 100 built-in analysis rules, including checks for cyclomatic complexity, method length, and code duplication.