12 Essential Rules for Successful Architecture Refactoring by Uber’s Raffi Krikorian

For developers, architecture design is the blueprint of software development; without it, building reliable applications is impossible. As applications evolve, original architectures often fail to meet business needs, scale, or new features, making thoughtful refactoring essential.

Below are Uber’s engineering manager Raffi Krikorian’s twelve rules for successful architecture refactoring, each accompanied by a practical checklist.

1. Determine the Purpose and Necessity of Refactoring

Analyze why the refactor is needed and consider alternative solutions before proceeding.

Checklist:

Is the refactor driven by business requirements or merely aesthetic concerns?

Have alternative solutions been evaluated with their pros and cons?

2. Define the Boundary of “Refactoring Completed”

Set clear, quantifiable goals or testable criteria to know when the refactor is finished.

Checklist:

Are the refactor goals measurable or testable?

Has the definition of completion been approved by stakeholders?

3. Incremental Refactoring

Adopt fast‑iteration and continuous‑delivery practices, delivering small changes and gathering feedback to adjust strategy.

Checklist:

Can the refactor be broken into small, feedback‑driven iterations?

Is progress regularly demonstrated to business or leadership?

4. Assess the Current Architecture State

Establish a baseline of the existing design to evaluate the impact of changes.

Checklist:

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

Can you define a baseline state for comparison?

5. Don’t Ignore Data

Recognize that architecture refactoring is fundamentally a data‑flow transformation; data requirements must be reflected in the design and used to validate outcomes.

Checklist:

Are business data needs reflected in the refactor design?

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

6. Manage Technical Debt

Use refactoring to repay existing debt without creating new debt; establish tracking, review, and training mechanisms.

Checklist:

Is there a system to track and record technical debt?

Are regular reviews or training on debt management conducted?

7. Avoid Vanity Technologies

Prioritize goal achievement over chasing trendy tools; evaluate new technologies with data and expert assessment.

Checklist:

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

Does the chosen technology have sufficient talent and experience support?

Are at least two alternative solutions considered?

8. Prepare for Pressure

Anticipate pressure from management, peers, and other departments; quantify results, set milestones, and communicate regularly.

Checklist:

Do senior leaders understand and support the refactor’s scope and timeline?

Are measurable outcomes defined and reported to management?

9. Understand the Business

Align refactor goals with business priorities, identify critical services, and engage business stakeholders.

Checklist:

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

Are key business areas and priority targets identified?

10. Prepare for Non‑Technical Factors

Recognize that commercial interests, management preferences, and politics can influence refactoring; adjust goals transparently.

Checklist:

When non‑technical factors arise, have you adjusted goals and informed stakeholders?

Are you open to, rather than resistant against, such influences?

11. Master Code Quality

Maintain high code quality through rigorous code reviews and documented standards.

Checklist:

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

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

12. Prepare the Team

Summarize all previous advice; ensure the team is ready and aligned before starting the refactor.

In practice, the effectiveness of these rules must be validated through real projects; experience remains the most valuable guide for engineers.