In September 2025, the technological bureau aerosystem.tech accepted a legacy Android tablet application for a comprehensive technical and stability audit. The software's targeted operational purpose is the automated aggregation, validation, and logging of real-time monitoring telematics from industrial cooling complexes operating at extreme capacities.
The project had been evolving since 2018. Over its 7-year continuous development lifecycle, the codebase passed through 4 different external vendors, gradually mutating into a highly coupled, chaotic monolith. The core technical showstoppers identified at the start of our anti-crisis engineering track included:
Architectural Degradation: A rigid, uncontrolled mix of Java (accounting for 25% of the codebase) and Kotlin without any defined layer boundaries. The software contained multiple obsolete, partially integrated architectural design patterns left by previous vendors.
Dependency Bloat: The system integrated over 60 third-party open-source libraries. Severe transitive dependency conflicts resulted in duplicate binaries, pushing the final production APK footprint to an unacceptable 450 MB.
Generative Technical Debt: For the last 6 months, code additions were pushed rapidly into production using unguided AI assistance. This approach caused an aggressive spike in coupling and heavily overinflated class definitions.
Runtime Instability: Complete breakdown of backward compatibility. The software consistently crashed upon launch in Android 15 and 16 target environments due to the presence of unmitigated Deprecated APIs.
Low Fault Tolerance: Automated test coverage had dropped below 5%. The resulting density of critical runtime crashes in production environments forced the client to maintain continuous engineering support squads to manually resolve application failures during night shifts.
Business Constraints: Deploy a fully stabilized, operational alpha build into live production environments within a strict 3-month hard deadline. To build a reliable workflow, we adopted the international standard IEEE 12207, which strictly defines software and systems lifecycle processes.
Phase 1. Requirements Engineering and Decomposition (IEEE 12207)
Technical documentation inside Confluence had not been updated since February 2022. Automated testing and defect reporting pipelines (GitLab CI -> Allure) were entirely broken and defunct. Working in close alignment with the client's operational engineering stakeholders, we engineered a rigorous system requirement specification containing over 200 measurable technical and performance metrics. This specification was immediately mapped into a strict matrix of Use Cases and validation Test Cases.
The core quantified baseline metrics targeted:
1. Hard daily limits on system-level runtime failures (ANRs and application crashes);
2. Maximum allowable failure rates within the telemetry ingestion and transaction flow of compressor stations;
3. Hard session retention times in the tablet device's hardware memory;
4. Predictable UI component state integrity during dynamic runtime configuration updates (such as real-time localization shifts, tablet orientation toggles, and Split-Screen multitasking);
5. Strict local data-caching architecture and data-interchange boundaries to guarantee offline-first continuity followed by safe, atomic batch synchronization.
Phase 2. High-Level Design (HLD)
The monolithic application structure was split into isolated, decoupled functional modules. The core business logic previously handled by bulky external open-source dependencies was reverse-engineered and re-implemented natively inside the product boundaries. This move eliminated transitive dependency overhead and drastically cleaned up the classpath.
Because the decomposition of the monolith was executed iteratively, maintaining build stability and interface integrity across merge requests was critical. To mitigate regression risks, we deployed a three-layer automated defense circuit directly inside GitLab CI:
1. Strict static analysis gates via customized Lint rules;
2. Mandatory execution of Unit and UI testing pipelines on every automated build;
3. Complete isolation of new architecture blocks behind Feature Toggles, paired with remote automated crash capturing.
Phase 3. Low-Level Design (LLD)
During the Low-Level Design phase, we defined explicit method signatures, internal data structures, and deterministic inter-module communication contracts. Backed by solid HLD blueprints, the team ran the generation of RFC (Request for Comments) and SRS (Software Requirement Specification) documentation in parallel with writing Unit test cases for specific code interfaces.
Within the first 3 weeks of the track, we locked down the foundational LLD documentation along with a comprehensive modular testing matrix. This covered approximately 8–10% of the entire targeted system architecture before a single line of production code was written.
Phase 4. Test-Driven Development (TDD)
All core engineering was executed strictly via TDD (Test-Driven Development) workflows using the "Red-Green-Refactor" cycle. Feature code was delivered via vertical architectural slices: starting deep within the data layer (Data Source) of a given module up through the business logic to the view layer (UI layer).
This approach eliminated the cognitive load of holding the entire legacy system's context in the engineers' heads. It guaranteed that code could only be merged into the primary repository if it completely satisfied the deterministic criteria of the pre-written automated tests.
Phase 5. Field Stabilization and Acceptance Testing
The implementation of a robust Feature Toggle mechanism enabled the safe delivery of progressive test builds straight onto the operational tablets used by active cooling complex field engineers. This process was executed without interrupting the core monitoring workflows. Whenever runtime requirements shifted, the changes were first validated inside the LLD documentation, backed by newly compiled automated tests, and only then pushed into production coding tracks.
During automated runs on highly customized, vendor-specific Android tablet firmware, several platform-dependent defects were identified:
1. Rendering pipeline breaks within data-dense tables under Split-Screen operations;
2. Abrupt Activity lifecycle termination triggered by aggressive, undocumented battery-saver algorithms built into the vendor's hardware tablets.
Thanks to the hard separation of architectural layers, these bugs were quickly isolated and mitigated entirely inside the isolated UI layer. The underlying business logic and Data layer remained completely untouched, eliminating any risk of widespread system regression.
Technical Outcomes
Following a 3-month anti-crisis engineering track structured around the IEEE 12207 lifecycle framework, the application was successfully transitioned into stable production operations:
1. Codebase Optimization: The total production source-code footprint was reduced by 20% by completely purging duplicate components and unverified generative AI debt.
2. Distribution Efficiency: The production APK file size dropped from 450 MB down to 112 MB due to the strict removal of redundant third-party library bloat.
3. Quality Assurance: Automated test coverage across the newly integrated modular architecture stabilized at a strict 95% threshold.
4. Runtime Reliability: The system's Crash-Free session rate settled firmly at an industry-leading 99.98% benchmark.
Business Efficiency and Financial Metrics
Transitioning the software system to a fault-tolerant, modular architecture significantly improved key operational indicators and optimized the product's overall technical support budget:
1. Liquidation of Night Support Shifts: Achieving the targeted structural stability completely eliminated the need for continuous, around-the-clock emergency support squads. The total cancellation of night shifts—which previously required double hourly billing rates (x2)—reduced direct ongoing operational support expenses by 40%.
2. Client Base Retention: Stabilizing the core telematics transaction flow and eliminating offline data loss brought technical-fault-driven customer churn (Churn Rate) down to a strict 0%.
3. Contract Recovery: Enterprise clients who had previously frozen their service contracts due to critical runtime defects completely restored their active paid subscriptions within two months following the initial alpha deployment.
4. Infrastructure Cost Mitigation: Cutting the production APK size by a factor of 4 led to a directly proportional drop in content delivery network (CDN) bandwidth costs and traffic distribution fees during mass fleet updates across the tablet pool.