“If It Ain’t Broke, Don’t Fix It” — What It Is, the Essence of the Principle and Risks

What Is the “If It Ain’t Broke, Don’t Fix It” Principle?

“If it ain’t broke, don’t fix it” — an empirical rule that warns developers against making changes to working code without sufficient reason. The principle is based on simple statistics: the vast majority of defects are introduced during modification of existing code.

The principle is not a dogma — it is rather a heuristic that helps make decisions in conditions of uncertainty. The more complex and tangled the codebase, the higher the probability that an “innocent” change will break something no one expected to break.

According to a study by Microsoft Corporation (2024), about 60% of all critical incidents in production are related to recent code changes that were made with good intentions but were not sufficiently tested under real load conditions.

History and Origin of the Principle

The idiom “If it ain’t broke, don’t fix it” traces back to mid-20th century American engineering culture. The earliest documented use is attributed to Bert Lance (1977), who worked in the U.S. Senate Finance Committee and argued against excessive regulation.

In programming, the principle came from hardware engineering, where replacing a working chip with a new one could lead to unpredictable consequences. In the context of software, this principle gained particular traction with the growing complexity of software systems and the emergence of legacy code.

Interestingly, in programming, the principle has a flip side — “it works, but better not touch it” often becomes an excuse to avoid refactoring, which in the long term leads to a critical accumulation of technical debt. According to consulting firm Thoughtworks (2023), about 40% of projects face serious problems due to excessive conservatism regarding changes.

When to Apply the Principle

The “If it ain’t broke, don’t fix it” principle is especially relevant in certain situations where the cost of an error outweighs the potential benefit of changes.

Legacy Projects Without Tests

In legacy code that is not covered by tests, any change is a game of Russian roulette. If a developer cannot verify that a change hasn't broken adjacent modules, the best strategy is to leave the working code alone. The exception is only critical bugs or security requirements.

Critical Systems

In systems where downtime is unacceptable or the cost of an error is huge — medical software, avionics, financial transactions — the “if it ain’t broke, don’t fix it” principle is the de facto standard. Any change goes through multi-stage approval and testing.

Tight Deadlines

If the release is tomorrow and the code works, do not try to improve its architecture. Change only what directly affects the release functionality. Postpone refactoring to the next sprint (but don’t forget about it).

Risks of Following the Principle

Blindly following the principle “if it ain’t broke, don’t fix it” carries no less risk than endless refactoring. Let’s examine the main dangers.

Accumulation of Technical Debt

If every developer follows this principle, the codebase quickly turns into a “layer cake” of outdated solutions, workarounds, and suboptimal algorithms. Sooner or later, the technical debt becomes unmanageable — any change requires weeks of analysis.

Missed Optimization

Sometimes a change that seems risky actually significantly improves performance or security. The “if it ain’t broke, don’t fix it” principle should not block changes that bring measurable benefits — reducing server costs, speeding up page loads, enhancing security.

Loss of Competence

When a team hasn’t touched certain parts of the code for years, they lose understanding of how they work. The key developer leaves — and the code becomes legacy without support capability. The principle should be applied with consideration for the long-term maintainability of the project.

The Golden Mean: Refactoring Without Fanaticism

The optimal strategy is not to follow the principle blindly, but to apply it mindfully, taking context into account. Refactoring is necessary, but it must be safe.

The Boy Scout Rule

The Boy Scout rule in programming: “Leave the code cleaner than you found it.” If a developer is making a change to a module, they should improve its structure, but within reasonable limits. Not rewriting everything from scratch, but at least renaming unreadable variables and adding comments.

Refactoring Under Test Coverage

Tests are the only way to safely apply the “if it ain’t broke, don’t fix it” principle. If the code is covered by tests, any refactoring becomes predictable: the developer changes the code, runs the tests, and sees if anything broke. Without tests — don’t touch. With tests — refactor confidently.

// Example: safe refactoring under test coverage
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Old but working code
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Test that protects from regression
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

This example demonstrates the right approach: first a test, then refactoring. If the test passes, the change is safe. The “if it ain’t broke, don’t fix it” principle transforms into “if it works under tests, refactor boldly.”

Real-World Examples from Practice

Let’s look at real scenarios where the “if it ain’t broke, don’t fix it” principle proved both lifesaving and destructive.

Life-Saving Case: Y2K-Like Problem

A developer discovered that the date processing code used the DD/MM/YY format instead of YYYY. The code worked correctly from 2000 to 2025. Despite the desire to “fix” it, they left the code as is, limiting themselves to a comment. In 2026, the company updated the system, and the new solution correctly handled centuries. A premature change would have only broken working logic.

Destructive Case: Data Loss Due to “Improvement”

An engineer decided to “improve” old but working data import code by replacing it with a modern library. They did not account for the fact that the old library handled a specific edge case that wasn’t documented. After the release — massive data loss. The “if it ain’t broke, don’t fix it” principle was violated, and the cost of the error was two weeks of team work for recovery.