Contents
Systems & Complexity
Section 1
The Core Idea
Refactoring is changing the internal structure of a system without changing its external behaviour — improving how it's built so that future change is easier, without (in principle) altering what it does. In code, that means renaming, extracting functions, simplifying conditionals, and removing duplication while keeping tests green. In organisations, it means restructuring teams, processes, or roles to reduce friction and improve flow without changing the product or strategy. The discipline is: improve the structure; preserve the behaviour; verify that you did.
The payoff of refactoring is deferred. You spend time and risk now to reduce cost and risk later. Systems that are never refactored accumulate cruft — duplication, unclear boundaries, hidden coupling — until change becomes expensive and dangerous. Refactoring is the antidote: pay down structural debt in small, safe steps so that the system stays malleable. The trap is refactoring for its own sake or refactoring the wrong thing while the real constraint is elsewhere. The strategic question is: what structure is blocking us, and is refactoring it the highest-leverage move right now?
Refactoring requires safety nets. In code, that's tests. In orgs, that's clear before/after states and a rollback plan. Without a way to verify that behaviour is unchanged, refactoring is just change — and risky. The best refactoring is small, frequent, and verified. Big-bang rewrites are rarely refactoring; they're replacement, with higher risk and longer payoff.
Section 2
How to See It
Refactoring shows up wherever someone is changing structure without changing purpose. Look for: "we're not adding features, we're cleaning up"; restructures that keep the same outputs; or incremental simplification with verification. The diagnostic: is the external behaviour (or output) unchanged while the internals are improved?
Business
You're seeing Refactoring when a company reorganises teams from functional silos to product-aligned squads. The goal is the same — ship product — but the structure is changed to reduce handoffs and clarify ownership. If done well, the same (or better) output with less friction. The refactoring is organisational; the "tests" are delivery and morale.
Technology
You're seeing Refactoring when engineers extract a shared module from duplicated code, rename variables for clarity, or break a large function into smaller ones. The API or user behaviour stays the same; the codebase is easier to change next time. Tests confirm nothing broke. Refactoring is routine in healthy codebases; its absence is technical debt piling up.
Investing
You're seeing Refactoring when a company simplifies its legal structure, merges subsidiaries, or cleans up the cap table. The economic substance is unchanged; the structure is easier to manage, report, or transact. The refactoring reduces future friction and cost.
Markets
You're seeing Refactoring when a trading desk consolidates systems or rewrites a critical path in a cleaner language. Execution and risk behaviour stay within bounds; the code or process is easier to extend and maintain. Refactoring here is infrastructure and process, with P&L and risk as the "tests."
Section 3
How to Use It
Decision filter
"Refactor when the current structure is blocking change or increasing risk — and when you have a way to verify behaviour is preserved. Do it in small steps. Don't refactor when the constraint is elsewhere (e.g. product or distribution); don't refactor without tests or equivalent safety."
As a founder
Refactor code and org when the structure is the bottleneck. Allocate time for tech debt and process cleanup in each cycle; avoid letting it pile up until a rewrite or reorg is the only option. The mistake: only refactoring in crisis, so every change is risky. The second mistake: refactoring while the real constraint is product, market, or distribution — structure is a means, not the goal.
As an investor
Assess whether the team refactors or only adds. Codebases and orgs that are never refactored become unmanageable; the cost shows up in slower shipping, more bugs, or talent leaving. Teams that refactor continuously keep optionality. The risk is refactoring as avoidance of the hard product or market work.
As a decision-maker
Use refactoring when structure is limiting progress and you can verify behaviour. Prefer small, verified steps to big rewrites. If you can't measure or observe "behaviour unchanged," refactoring is just change — add explicit success criteria and rollback so you know when to stop or reverse.
Common misapplication: Refactoring without verification. You think behaviour is unchanged but you've introduced bugs or side effects. The fix: tests, staging, or clear before/after metrics before calling it refactoring.
Second misapplication: Refactoring instead of solving the real problem. The bottleneck is demand or product; restructuring the org or code feels like progress but doesn't move the needle. Refactor when structure is the constraint.
Section 4
The Mechanism
Section 5
Founders & Leaders in Action
Satya NadellaCEO, Microsoft, 2014–present
Nadella refactored Microsoft's structure and culture without changing the company's core businesses. He flattened silos, shifted to growth mindset and collaboration, and reorganised around cloud and platforms. The external "behaviour" — selling software and services — stayed; the internal structure was improved so the company could ship and compete differently. The refactoring was organisational; the verification was growth and talent retention.
Jeff BezosFounder & CEO, Amazon, 1994–2021
Bezos applied refactoring at scale: two-pizza teams, single-threaded ownership, and APIs as boundaries between services. The goal was to keep the organisation and systems changeable — improve structure so that new initiatives could be built without rewriting the whole. Amazon's "you build it, you run it" forced teams to live with their structure and refactor when it hurt. Refactoring was continuous, not one-off.
Section 6
Visual Explanation
Refactoring: change internal structure; preserve external behaviour. Verify with tests or outcomes. Small steps reduce risk.
Section 7
Connected Models
Refactoring connects to technical debt, modularity, and constraints. The models below either describe the problem refactoring solves (Technical Debt), prescribe structure (Modularity), or warn against misuse (Premature Optimisation).
Reinforces
Technical Debt
Technical debt is the cost of deferred refactoring. Refactoring pays it down. The two are opposite sides of the same coin: debt accumulates when you don't refactor; refactoring is the payment.
Leads-to
Modularity
Modularity is structure with clear boundaries. Refactoring often aims at better modularity — extract modules, reduce coupling. Refactoring is the activity; modularity is a target structure.
Reinforces
[Theory of Constraints](/mental-models/theory-of-constraints)
The constraint limits progress. When the constraint is structure (e.g. codebase or org), refactoring is the lever. When the constraint is elsewhere, refactoring is misdirected. Find the constraint first.
Reinforces
[[Feedback](/mental-models/feedback) Loops](/mental-models/feedback-loops)
Refactoring needs feedback: tests, builds, staging. Feedback loops confirm behaviour is preserved. Without them, refactoring is just change with unknown risk.
Leads-to
[Repeatable Systems](/mental-models/repeatable-systems)
Repeatable systems depend on clear structure. Refactoring keeps structure aligned with the problem so that repetition stays reliable. Debt obscures structure; refactoring restores it.
Tension
Premature Optimisation
Premature optimisation is improving the wrong thing too early. Refactoring can be premature when the real constraint is product or market — you're improving structure while the system may need to be replaced. Refactor when structure is the bottleneck.
Section 8
One Key Quote
— Martin Fowler, Refactoring (1999)"Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior."
The definition is exact: internal structure changes; external behaviour does not. The discipline is verification — tests or equivalent — so that "external behavior" is not assumed but checked.
Section 9
Analyst's Take
Faster Than Normal — Editorial View
Refactor when structure is the constraint. If the bottleneck is product, distribution, or market, refactoring code or org is secondary. When the bottleneck is "we can't change this without breaking it," refactoring is the move. Allocate time every cycle so debt doesn't compound.
Small steps, verified. Big rewrites are rarely refactoring; they're replacement. The risk and cost are higher. Prefer many small refactors with tests (or clear before/after metrics) so that each step is safe and reversible.
Verification is non-negotiable. Refactoring without a way to confirm behaviour is just change. In code, that's tests. In org, that's clear outcomes (delivery, retention). If you can't verify, you're guessing — and the refactor may be introducing hidden failure.
Section 10
Summary
Refactoring is changing internal structure without changing external behaviour. It pays down structural debt so future change is easier. Do it in small, verified steps; use tests or clear outcomes as the safety net. Refactor when structure is the constraint — not when the constraint is elsewhere.
Section 11
Further Reading
01
Book
The canonical text. Behaviour-preserving transformations and the discipline of refactoring with tests.
02
Book
How to refactor when tests are missing: add tests, then refactor. Practical guide for paying down debt in existing codebases.
03
Book
"Don't live with broken windows": refactor as you go so that the codebase stays habitable. Related to technical debt and continuous improvement.
04
Book
Evidence that technical debt and refactoring practices correlate with delivery performance. Refactoring as a capability, not a cost.
05
Book
Organisational refactoring: when and how to restructure so that behaviour (output) is preserved or improved while structure is simplified.
Summary: Refactoring is improving internal structure while preserving external behaviour. Do it continuously in small, safe steps backed by tests — in codebases, org charts, and processes alike — so complexity never compounds into a rewrite.
Why this matters next
mental modelsLeverage
Refactoring applied the Leverage mental model
mental modelsTechnical Debt
Refactoring applied the Technical Debt mental model
mental modelsTheory of Constraints
Refactoring applied the Theory of Constraints mental model
mental modelsRepeatable Systems
Refactoring applied the Repeatable Systems mental model
mental modelsScale
Refactoring applied the Scale mental model
mental modelsQuality
Refactoring applied the Quality mental model
Frequently asked questions
What is Refactoring?
Refactoring is a mental model used for better thinking and decision-making.
How do you apply Refactoring?
To apply Refactoring, identify situations where this framework is relevant, then use it as a lens to evaluate your options and decisions. The model is most useful when combined with other complementary mental models.
What category does Refactoring fall under?
Refactoring falls under the Systems & Complexity category of mental models. Other models in this category can be found on the Systems & Complexity hub page.
Why is Refactoring important?
Refactoring is important because it provides a structured way to think about problems that would otherwise be approached with intuition alone. Understanding this model helps you avoid common reasoning errors and make better decisions.
Continue exploring
LEANEMFLGLL(
Mental model
Lollapalooza Effects
When multiple cognitive biases or forces act in the same direction simultaneousl
Mental model
Antifragility
Beyond resilience — some systems actually gain from disorder, volatility, and st
Mental model
Emergence
Complex system-level properties that arise from simple interactions between indi
Mental model
Feedback Loops
Circular causal chains where the output of a system feeds back as input — either
Mental model
Gall's Law
A complex system that works is invariably found to have evolved from a simple sy
Mental model
Leverage (Systems)
Places within a complex system where a small shift produces large changes — Mead
More like this, in your inbox
I send a newsletter every week — free, no spam, unsubscribe anytime.