12 Rules for Successful Architecture Refactoring – Insights from Uber’s Raffi Krikorian

For developers, architecture design is the most critical phase of software development, akin to having a blueprint before building a house; mature patterns exist, but evolving applications often outgrow their initial architectures, leading to unmet business needs and limited extensibility.

When an architecture can no longer satisfy requirements, teams must avoid common pitfalls and aim for successful refactoring, a challenge many architects face.

Below are Uber’s engineering director Raffi Krikorian’s twelve rules, accompanied by brief interpretations to guide practitioners.

1. Define the Purpose and Necessity of Refactoring

Before undertaking a costly, disruptive refactor, analyze the reasons and alternatives, ensuring the goal directly addresses a business need and is the best solution; otherwise, consider options like scaling resources.

What is the concrete reason for refactoring – business demand or aesthetic preference?

Are there alternative solutions, and have their pros and cons been evaluated?

2. Define the Boundary of “Refactor Complete”

Set quantifiable targets or testable criteria for completion; without clear requirements, specifications remain vague and teams lack a concrete endpoint, risking endless work.

Is the refactor goal measurable or testable?

Has the definition of completion been approved by business owners or leadership?

3. Incremental Refactoring

Apply fast‑iteration, continuous‑delivery practices to architecture changes, delivering small, feedback‑driven increments; if a full‑scale rewrite is unavoidable, use a parallel copy system for cautious testing before migration.

Can the refactor be broken into small iterations with rapid feedback?

Are interim results regularly shown to business stakeholders?

4. Assess the Current Architecture State

Establish a baseline understanding of the existing design before starting; many teams begin refactoring without fully grasping current constraints, leading to costly re‑work.

Do you understand the current design, its original intent, and selection rationale?

Can you define a baseline state for comparison?

5. Do Not Ignore Data

Architecture refactoring is fundamentally a data‑flow transformation; ensure business data requirements are reflected in the design and use real data to validate the impact.

Are business data needs incorporated into the refactor design?

Can actual data be used to verify the refactor’s effectiveness?

6. Manage Technical Debt

Treat refactoring as an opportunity to repay technical debt, not to create new debt; establish a culture of quality, allocate time for debt reduction, and track debt systematically.

Does the team have a mechanism to track and limit technical debt?

Are there regular trainings or reviews focused on debt management?

7. Avoid Vanity Technologies

Prioritize solutions that meet refactor goals over trendy stacks; evaluate new technologies with data and expert judgment, ensuring sufficient talent and experience before adoption.

Is the technology choice backed by solid data and expert evaluation?

Do selected technologies have mature talent pools and proven success?

Are at least two alternative solutions considered?

8. Prepare for Pressure

Recognize that refactoring often receives less visible appreciation than new product launches; mitigate pressure by setting milestones, quantifying outcomes, and regularly communicating progress to stakeholders.

Has senior management endorsed the refactor and its timeline?

Does the plan include measurable deliverables and regular status updates?

9. Understand the Business

Deep business knowledge helps prioritize refactor targets, identify critical components, and align technical work with real business value.

Have you discussed and confirmed business goals with the relevant departments?

Are key business areas and priority refactor targets identified?

10. Prepare for Non‑Technical Factors

Accept that commercial interests, management preferences, and political dynamics can influence refactor decisions; stay flexible, adjust goals when needed, and communicate changes transparently.

When non‑technical factors arise, do you adjust goals and inform all stakeholders?

Are you open to adapting rather than resisting external influences?

11. Master Code Quality

High code quality is essential for safe refactoring; enforce code reviews, maintain quality standards, and embed quality checks into the workflow.

Does the team prioritize code quality with clear incentives or penalties?

Is there documented code‑quality standards and a review process?

12. Prepare the Team

The final rule summarizes the previous advice: ensure the entire team is aligned, equipped, and motivated to undertake the refactor.

In conclusion, while Raffi Krikorian’s guidelines provide a solid framework, their effectiveness ultimately depends on real‑world practice and continuous learning.

Source: infoq / 崔康