How Four Teams Stopped Postponing the Refactoring They Knew They Needed

Colette Des Georges

As an engineering leader, you don’t need to be told your codebase needs attention. The issue isn’t awareness – it’s the rational risk calculation that follows.

For four teams, that calculation kept producing the same answer: defer. They found a way out not by avoiding the calculation, but by changing what went into it.

To refactor or not: The cost of a rational decision

Regression risk is a perennial concern for developers considering refactoring. A 2014 study of 328 professional engineers at Microsoft found that 76% considered it likely that refactoring would introduce subtle bugs or regressions. In a 2022 CMU/SEI survey, 71% of 107 senior industry practitioners reported that they wanted to undertake large-scale refactoring but couldn’t – primarily because of the anticipated cost and competing feature priorities. Only 6% said the anticipated value of refactoring was too low.

That means deferring refactoring has traditionally been the default choice in the short term.

The pain of refactoring that disrupts delivery is immediate and concrete. Sprint commitments slip, customer-facing timelines move, and your team gets the blame.

The architectural pain of deferring an improvement is also real, but it shows up later, spread across dozens of small slowdowns that never individually force a response.

Immediate pain vs. delayed pain means refactoring keeps losing.

The calculation changes only when the cost of making the change itself drops. That happens specifically when developers can:

• See the full impact of a refactoring operation across the entire codebase before committing to it.
• Reverse the entire thing as a single operation if something goes wrong.

At that point, the potential for short-term disruption shrinks and long-term benefits start winning more often.

Here’s what that point looked like for four teams.

Wiz: Keeping a million-line monorepo changeable

Wiz, acquired by Google for $32 billion in March 2026, is a cloud security platform trusted by over half of the Fortune 100 to identify and remove critical risks across major cloud environments.

Wiz standardized on GoLand, JetBrains’ Go-specific IDE, for its engineering team working on a massive monorepo with millions of lines of code written mostly in Go.

In a monorepo of that scale, the refactoring spillover problem is structural. Any change can affect dozens of services, packages, and dependencies across teams. When tools struggle to keep up with repository size – when indexing takes hours and still produces freezes – developers are cautious. They touch less and defer more. The codebase gets harder to change as the teams that need to change it slow down.

GoLand was the only tool that kept developers productive at that scale rather than adding to their workload. Refactoring operations all resolved correctly across the entire codebase. Project-wide navigation reduced the cognitive overhead of working in a system too large for any one developer to hold in their head.

“Refactoring is easy. Moving packages, renaming, deleting, adding, extracting – all of these work very well, quickly, and almost always flawlessly, regardless of the size of the refactor/change.”

– Roy Reznik, Wiz Co-Founder

The result wasn’t a cleanup initiative. It was a sustained ability to keep modifying a system that, by any conventional measure, should have become progressively harder to touch.

IT Manufactory: From manual verification to confident cross-stack changes

IT Manufactory builds Digital Automotive, a platform for strategy, acquisition, finance, and change management in the automotive industry. With a team of nine developers working across Java backend modules and React frontend components, the company was in a phase of active product development. Significant changes needed to happen in a lot of places, frequently.

The specific risk was cross-stack impact. Breaking changes that touched both Java modules and React components simultaneously required manual verification across the full dependency chain. There was no reliable way to know in advance what a change would affect. The practical effect was that engineers either avoided large architectural changes or absorbed the overhead of extensive manual checking before committing to them.

Standardizing on IntelliJ IDEA and WebStorm changed that overhead calculation directly. Deleting a file, renaming a function or variable, extracting methods – operations that previously required manually hunting for every reference across the full codebase – became single confirmed actions the IDE handled completely.

“Breaking changes and refactoring need to happen in multiple Java modules and React components. Making such huge changes would not have been possible without JetBrains products.”

– Varij Kapil, Software Developer, IT Manufactory

The team didn’t stop making large changes. They stopped paying the manual verification tax on every one of them.

NutriAdmin: Keeping a lean team shipping during a framework migration

NutriAdmin is a SaaS platform serving dietitians and nutritionists. The lean development team originally wrote the frontend in AngularJS, which created a specific and time-limited problem when Google shifted support toward Angular. Continuing to ship on AngularJS meant accumulating migration debt on top of feature debt. Deferring the migration meant the eventual cost kept growing.

For a team focused on shipping continuously, large-scale refactoring without reliable tooling is both risky and operationally impractical. Moving, renaming, splitting, and restructuring files manually across a growing codebase is the kind of work that stops feature delivery entirely while it’s happening.

WebStorm’s static analysis support for AngularJS was the specific capability that made modernization viable alongside ongoing development. The IDE resolves references and dependencies within AngularJS code – a framework with declining tooling support elsewhere – while also covering Node.js and React in the same environment. Refactoring operations that would otherwise require careful manual coordination across the full codebase became operations the IDE handled.

“It is a delight to refactor code with WebStorm. I have been able to simultaneously move, rename, split, and restructure over a hundred files as I refactor my project with confidence and efficiency. A big refactoring operation could be a nightmare in a less advanced IDE, and many developers could sometimes be hesitant to periodically maintain and improve their codebase, leading to the accumulation of technical debt and a degrading codebase.”

– Diego Oliveira Sanchez, Co-Founder, NutriAdmin

The migration didn’t happen as a separate initiative. It happened continuously alongside feature delivery because the tooling made that viable.

SEOBUK PRESENT operates a global franchise of self-service photo studios from its base in South Korea. The platform spans hardware control, backend services, Unity applications, and server communication across cameras, printers, payment terminals, and customer-facing workflows. The engineering team works in C# on Windows across a domain where software and hardware are tightly coupled.

In that environment, the blast radius of a code change isn’t limited to other services. The platform integrates hardware SDKs, device drivers, spoolers, and asynchronous timing across the full stack. Even a small naming change carries a high risk of breaking existing functionality across tightly coupled systems. The operational cost of getting it wrong is immediate and visible.

Standardizing on IntelliJ IDEA for backend services and Rider for C# and Unity development gave the team project-wide refactoring previews before any change was committed. Everything that would be affected across the full solution was visible pre-operation. Git integration with line-level history visibility allowed engineers to trace what changed and why, reducing the investigation overhead when something needed to be understood or reversed.

“When the team adopted Rider, the response was immediate. Onboarding speed, review turnaround, and regression handling improved noticeably, and a culture of small and frequent changes took root.”

– Won, Development Team Lead, SEOBUK PRESENT

The shift wasn’t from large risky changes to no changes. It was from large, deferred-until-unavoidable changes to small continuous ones that the team could make with confidence.

The refactoring calculation looks different from here

These four teams don’t share a stack, a size, or a problem type. What they share are the factors that changed the calculation: the ability to see what a refactoring operation would touch across the entire codebase before committing to it, and the ability to reverse everything as a single operation if something went wrong.

For every major language represented here – Go, Java, React, AngularJS, C#, and Unity – a JetBrains IDE enabled those abilities. There’s one for every major language your team uses, too. The All Products Pack puts all of them under one license, so the cost of access stays fixed while the value of consistent refactoring compounds over time.

Find out how pre-change visibility alters the refactoring calculation for your team. 

Learn more about JetBrains for Businesses.