跪拜 Guibai
← All articles
Android · Coding Standards · Programmers

Tech-Improvement Work Keeps Getting Killed. Here's What Survives.

By Coffeeee ·
Read original on juejin.cn ↗ Google Translate ↗ Alt translation

When product managers control requirement creation and measure everything against revenue impact, engineering teams lose the ability to pay down technical debt through official channels. The workaround is to treat tech-improvement as internal hygiene—done in small phases without competing for business scheduling—and to lean on AI for the grunt work that makes the cost too small to argue about.

Summary

Across multiple companies, the same pattern holds: architecture upgrades, infrastructure work, and performance fixes get indefinitely postponed or cut outright. The calculus changed around 2022 when traffic growth stopped covering the cost of internal engineering work. Managers now ask for specific data—exactly how many ANRs will this fix, and in which scenarios—and most tech-improvement proposals can't answer.

The few that survive are infrastructure optimizations with immediate, visible results and performance/stability work that produces quantifiable metrics. Code-style nitpicking is a waste of a ticket; it belongs in pre-commit hooks. Architecture overhauls carry the highest risk of being abandoned mid-flight.

AI tooling shifts the equation slightly. Refactoring, test generation, and documentation that once took days can finish in hours, making the labor cost low enough that leadership stops scrutinizing. But AI-generated code also introduces uneven quality and new review overhead, so the net effect is that infrastructure and performance work gain breathing room while broad rewrites remain dangerous.

Takeaways
Tech-improvement requirements fall into four buckets: architecture upgrades, infrastructure optimization, code nitpicking, and performance/stability work.
Architecture upgrades like MVP-to-MVVM or componentization take 6–12 months and carry high risk of being abandoned mid-project.
Infrastructure work such as CI/CD speed-ups and monitoring delivers immediate, visible results with lower risk.
Code-style enforcement belongs in pre-commit hooks, not in dedicated requirement tickets.
Performance and stability fixes produce quantifiable metrics and can be woven into regular business development.
Since roughly 2022, declining traffic growth broke the old model where business revenue covered the cost of internal engineering work.
Managers now demand quantitative proof: exact ANR reductions, specific cost savings, and scenario-level impact data.
Proposing tech-improvement through product managers guarantees it loses against business requirements that carry clear KPIs.
Phased delivery—splitting a 26-person-day effort into small, shippable increments—prevents mid-project cancellation.
AI accelerates refactoring, test writing, and documentation enough to make infrastructure and performance work politically viable again.
AI-generated code quality is inconsistent, so any AI-assisted tech-improvement must budget extra review and testing effort.
Conclusions

The core conflict is structural: product managers control the requirement pipeline and optimize for revenue KPIs, so any work without a direct revenue line is filtered out before engineering can even evaluate it.

Treating tech-improvement as internal team hygiene—like cleaning the house—sidesteps the gatekeeping problem entirely, but it requires discipline to carve out time without official tickets.

The shift from qualitative to quantitative justification is a net positive. If a team cannot articulate the concrete impact of a refactor, it probably should not be done.

Architecture migrations that take a year are a bet on organizational stability that most companies cannot make right now; the risk of cancellation mid-way is priced too high.

AI changes the economics of tech-improvement not by making it more strategic, but by making it cheaper—when a refactor costs hours instead of days, the approval bar drops.

The hidden cost of AI-assisted tech-improvement is the review burden: generated code that looks plausible but is subtly wrong creates a new category of technical debt.

Concepts & terms
Tech-improvement requirements
Internal engineering work tickets covering architecture upgrades, infrastructure optimization, code standards enforcement, and performance/stability fixes—distinct from user-facing feature work.
Pre-commit hooks
Automated checks that run before code is committed to a repository, used to enforce naming conventions, formatting, and other code-style rules without a dedicated project ticket.
ANR
Application Not Responding—an Android system dialog shown when an app's main thread is blocked for too long, a key stability metric that teams track and fix.
Componentization
Breaking a monolithic Android app into independently buildable, reusable modules—a multi-month architecture migration with high abandonment risk.
Source: juejin.cn ↗ Google Translate ↗ Backup ↗