Excellence Is a Habit: Why Shipping Software Beats Perfection

posted on November 17, 2025

The urge to “rewrite it all” is often disguised as a pursuit of excellence.

We’ve all seen the pattern. An engineer opens a file and becomes allergic to what they see. Maybe it’s messy legacy code, a “temporary” hack that is now celebrating its third birthday, or an architectural pattern that no longer fits the scale of the application.

The instinct is to fix it. To overhaul it. To make it clean, modern, and “right.” This is a good instinct! We should seek to improve things as we go, and developing that conscientiousness is vital for any senior engineer.

However, there is a dangerous trap that lies between the urge to fix and the execution of that fix: The Big Bang Refactor.

The Anatomy of the Trap

Why do so many smart teams fall into this trap? It rarely starts with malice or laziness. It starts with the Illusion of Control.

When a team looks at a messy codebase, they see chaos. They see risk. They see a system that fights them every time they try to add a feature. The “rewrite” promises a return to order. It promises a clean slate where variables are named correctly, race conditions are handled gracefully, and the database schema makes sense.

But software is rarely that contained. You decide to rewrite the authentication logic, which requires updating the user model. That breaks the reporting module, which relies on a deprecated library. To update that library, you need to upgrade the framework version.

Suddenly, you aren’t refactoring a module; you are unearthing an archeological dig site.

The team stops shipping features to focus on “stabilization.” They hold everything back until it is “perfect.” They keep adding prerequisites and dependencies to the update. The scope explodes, momentum dies, and the mental context required to hold this massive refactor in your head becomes exhausting.

The Clinical Signs of Stagnation

This situation quickly devolves into a morass where nothing gets shipped. It is a paralysis that bleeds the company of resources and the team of morale.

If you are wondering if your team is currently caught in this trap, look for these clinical symptoms:

• The “Long-Lived Branch” Syndrome: You have feature branches that have been open for weeks (or months). They are constantly needing to be rebased, and every rebase introduces new conflicts that take days to resolve.
• Fear of Deployment: Releasing to production feels like a military operation rather than a routine task. There are “Freeze Weeks,” massive manual QA checklists, and a general sense of dread on release day.
• The “One More Thing” Justification: Every time you ask for an ETA, the answer is, “It’s basically done, we just found one edge case in the legacy data we need to handle.” This happens four weeks in a row.
• Silence in the Metrics: The tickets are moving, code is being committed, but the actual user-facing changelog is a flatline. You are spending money, but value isn’t leaving the building.
• Context Collapse: The engineers are so deep in the weeds of the complex refactor that they can no longer easily explain to stakeholders why things are taking so long. They are mentally exhausted from juggling the complexity of a “perfect” architecture that doesn’t exist yet.

This form of paralysis is incredibly expensive.

For the person writing the payroll checks, this is a nightmare. While the engineering team is stuck in the mud of a “perfect” architecture that hasn’t shipped yet, value delivery hits zero. Customers don’t get what they need, stakeholders lose trust, and the product is held hostage by its own codebase.

The Solution: Build The Skill of Shipping

The best teams I have worked with fight this urge because they have developed a superior skill: Shipping.

We tend to view shipping as merely the final step in the process—the button you press when the work is done. But shipping quickly and consistently is a skill in its own right. It is a discipline just as important as selecting the right design pattern or writing unit tests.

Most teams aren’t practicing this skill. If they did, they would discover a counter-intuitive truth: A messy system that is improved daily is infinitely easier to manage than a “perfect” system that is stuck indefinitely.

If you want to move quickly, you must build the habit of shipping expediently as a team.

How to Break the Paralysis

Moving from a “rewrite” mindset to a “shipping” mindset requires a shift in strategy:

1. Aggressive Incrementalism: Never hold a refactor hostage for a feature, and never hold a feature hostage for a refactor. Break the work down until it fits in a single day.
2. The Boy Scout Rule: Clean the mess while you deliver value. Leave the file slightly better than you found it. Over a year, this transforms a codebase.
3. Shrink the Batch Size: If a change requires two weeks of coding before it can be merged, the batch size is too big. The risk of failure increases exponentially with the size of the batch.

Excellence isn’t about having a codebase that looks like it belongs in a textbook. Excellence is the ability to navigate complexity and deliver value continuously.

Let’s Get You Shipping Again

Changing a team’s engineering culture is difficult. It often feels safer to stay in the “rewrite” phase because you don’t have to face the reality of production bugs. But that safety is an illusion that costs you money every single day.

I help engineering teams break out of paralysis. I work with leadership to implement the workflows, architectural patterns, and cultural shifts required to turn shipping from a scary event into a boring, daily habit.

If your team is stuck spinning its wheels on a rewrite that never seems to end, or if you are seeing the symptoms of stagnation listed above, we need to talk.