“This new change is not consistent with our codebase.”

I’m used to hearing this when adding improvements to legacy codebases. It sounds like a call for consistency, but in reality, it’s resistance to change.

With over a decade of software engineering experience, I’ve learned that consistency alone is not a virtue—especially when it tries to preserve bad design.

Legacy systems often carry a heavy mix of technical debt: duplicated logic, spaghetti code, ignored principles, and no test coverage. If we keep adding features on top of poor design just for consistency, we’re only adding to the mess.

Teams often resist change because:

• They don’t fully understand better design choices
• They fear the cost of learning and refactoring
• They mistake familiarity for stability

What I’ve found to work better:

• Introduce change incrementally, limited to new development
• Let small wins demonstrate real benefits
• Frame improvements in terms of business impact rather than code quality
• Encourage ongoing learning of software design fundamentals

Good design isn’t a luxury—it’s necessary to create software that can be safely maintained, extended, and improved over time.

Sometimes, breaking consistency is exactly what’s needed to restore a codebase’s health.

#clean code #legacy system #refactoring #software design