Refactoring
The disciplined practice of changing the internal structure of code without changing its external behaviour — improving design, reducing complexity, and paying down technical debt without altering functionality.
Definition
Refactoring is the practice of restructuring existing code without changing its external behaviour, with the goals of improving readability, reducing complexity, and making future change easier. The term is precise: a change that alters behaviour is not refactoring, it is rewriting. Refactoring relies on automated tests to prove that behaviour is preserved.
Why It Matters
Code that is not refactored decays. Every shortcut, every "we'll clean it up later", every workaround accumulates as technical debt that slows future delivery and increases defect risk. Refactoring is the engineering discipline that prevents that decay. Teams that refactor continuously sustain velocity over years; teams that do not eventually grind to a halt and demand a rewrite.
Common Refactorings
- Extract Method / Extract Function
- Rename for clarity
- Replace conditional with polymorphism
- Introduce parameter object
- Move method / move field
- Replace magic number with named constant
- Decompose long method
Real-World IT Example
A 9-year-old order-processing service had grown to 14,000 lines in a single class. Adding any feature took 3–4× the estimate due to risk of regression. Over six months, the team refactored the class into 22 cohesive components using parallel-change ("expand and contract") patterns, guarded by 1,800 newly added tests. Post-refactor, the same feature complexity took 0.8× the estimate. Velocity nearly doubled.
Real-World Construction Analogue
Construction has a parallel concept: constructability rework during design development — restructuring drawings, specifications, and details to be easier to build without changing the building. A $480M hospital design team refactored the MEP coordination model over four iterations, reducing field clashes from 1,200+ to under 40 without changing any architectural or programmatic requirement.
Common Mistakes
- Refactoring without tests. Behaviour-preservation cannot be proven; this is rewriting.
- Big-bang refactors. Long-lived branches fall behind reality; small steps are safer and faster.
- Mixing refactor and feature. Reviewers cannot tell which change caused which effect.
- Refactoring for its own sake. Refactor in service of upcoming feature work, not as a hobby.
- Skipping the review. Refactors deserve review precisely because they touch so much.
Expert Tips
- Refactor as part of feature work — "leave the campsite cleaner than you found it".
- Use the IDE's built-in refactoring tools; manual rename and extract are error-prone.
- Commit refactors separately from feature changes; reviewers can verify each.
- Pair on hard refactors; the second pair of eyes catches behavioural drift.
- Maintain a "refactoring backlog" of known smells, addressed opportunistically.
Practical Lessons Learned
- Teams that refactor continuously rarely need to rewrite; teams that never refactor eventually demand a rewrite that almost always overruns.
- The single highest-leverage refactor in legacy code is usually the addition of seams that allow new tests to be written.
- Refactoring under deadline pressure is unwise; refactoring before each new feature in the area is wise.
Key Takeaways
- Refactoring changes internal structure without changing external behaviour.
- It depends on automated tests to prove behaviour is preserved.
- Small, continuous refactors beat big-bang efforts.
- The economic case is sustained velocity and avoided rewrites.
- The same idea — restructure without changing intent — applies to design refactoring in construction.
Related Encyclopedia Entries
Related Research Articles, Case Studies & Tools
Frequently Asked Questions
Is refactoring the same as rewriting?
No. Refactoring preserves external behaviour; rewriting changes it.How do I justify refactoring time?
Frame it in terms of future feature velocity and defect-rate reduction, not abstract code quality.Do I need tests before refactoring?
Yes — tests are how you prove behaviour is preserved.Should refactoring be a separate sprint?
Better to interleave with feature work; dedicated refactoring sprints rarely deliver expected results.What is the biggest pitfall?
Mixing refactor and feature in the same commit. Reviewers cannot tell which change caused which effect.How do I prioritise refactors?
Refactor the code you are about to change. Address smells opportunistically; never refactor unrelated code under deadline pressure.Does refactoring apply to infrastructure-as-code?
Yes — Terraform, Helm charts, and pipelines benefit from the same disciplines.What is a common misconception about Refactoring?
That the topic is well-defined across all references. In practice, definitions vary between PMBOK, PRINCE2, AACE and ISO 21500 — this entry uses the definition most aligned with field practice on capital projects, and flags where the standards diverge.Which related encyclopedia entries should I read alongside Refactoring?
Read Earned Value Management, Critical Path Method and the DCMA 14-point assessment next. The full A–Z is available in the PMMilestone Encyclopedia, and quick one-line definitions live in the PM Glossary on the flagship platform.How does Dr. Hassan Eliwa's research treat Refactoring?
Dr. Hassan Eliwa's research focuses on owner-side project controls, schedule integrity and forensic delay analysis on capital construction and power programmes. Refactoring is treated through that lens — what a planning or controls engineer is expected to do with it on a live project, not its textbook definition alone. See the full research library at PMMilestone Research Articles.How is Refactoring defined on PMMilestone Research & Insights?
The disciplined practice of changing the internal structure of code without changing its external behaviour — improving design, reducing complexity, and paying down technical debt without altering functionality. For the full treatment, see the definition, principles, applications and related entries above — every encyclopedia entry follows the same research-grade structure.
People also ask
Follow-up questions practitioners search for next — each one points to the calculator, template or reference entry that answers it.
Which calculator on PMMilestone.org applies here?
The integrated EVM workbook covers most cost-schedule diagnostics. EVM Calculator ↗
Where is this in the glossary?
Quick-lookup definitions across 1,200+ PM terms. PM Glossary on PMMilestone.org ↗
Which learning track covers this end-to-end?
Structured tracks from beginner planner to programme controls director. Project Controls Academy ↗
Which book goes deeper than this entry?
Practitioner field handbooks with worked numerical examples. Books & Publications ↗
Related Entries
Further reading on PMMilestone.org
Curated companion resources hosted on the flagship platform, PMMilestone.org.
- For practitioners who want to go deeper, the Learning Tracks.
- Engineers researching this topic typically continue with the Books & Publications.
- A practical companion to this entry is the EVM Calculator.
- Closely related on the flagship platform is the Schedule Health Checker.
- Useful alongside this article is the PMMilestone.org knowledge hub.