"It works" might be the most dangerous phrase in software engineering. Not because it's false — the code does work. But because it kills the conversation about whether it works well enough.
We've walked into dozens of codebases where everything technically functions. The API responds. The data gets saved. The page loads. But the API takes 4 seconds. The save operation locks the database. The page loads with a 12MB JavaScript bundle. And when you ask about it, the answer is always the same: "Yeah, but it works."
The hidden tax
Slow, brittle code that "works" is not free. It imposes a tax on everything around it — a tax that's real but rarely measured:
- Developer velocity. When a test suite takes 45 minutes, developers stop running it locally. They push and pray. CI becomes the bottleneck. What should take an hour takes a day.
- Debugging time. Brittle code produces intermittent failures. The kind that pass on retry, that only happen under load, that nobody can reproduce consistently. These bugs eat weeks.
- Onboarding cost. New engineers look at the code and can't understand why it's doing what it's doing. The workarounds have workarounds. The "temporary" fix from 2019 is still there. Getting productive takes months instead of weeks.
- Feature velocity. Every new feature built on shaky foundations takes longer. Estimates grow. Confidence drops. The backlog grows faster than the team can deliver.
- User experience. That 4-second API response? Users notice. They don't file bug reports — they just leave. The business sees declining engagement and blames the product, not the code.
None of these costs show up on a dashboard. There's no alert for "your team is 40% slower than it could be." But the impact is there, compounding every sprint.
Why "it's fine" wins
The reason brittle code survives isn't technical. It's organizational. Optimization competes with features for engineering time, and features have advocates — product managers, customers, revenue targets. Optimization's advocate is usually a frustrated engineer who struggles to quantify the cost in business terms.
"We need to refactor the billing module" loses to "We need to ship the enterprise dashboard" every time — unless you can articulate what the billing module is costing you.
How to make the case
We've helped teams build this case many times. The key is translating technical debt into metrics the business already cares about:
Measure what's slow
Before you argue for optimization, measure the current state. How long does the CI pipeline take? What's the P95 response time on critical endpoints? How many hours per sprint are spent on "flaky test" investigations? Hard numbers beat opinions.
Calculate the cost
If your CI pipeline takes 40 minutes and every developer runs it 5 times a day, that's over 3 hours of blocked time per developer per day. Multiply by team size and average salary. The number is usually shocking.
A 10-person team with a 40-minute CI pipeline wastes roughly 150 developer-hours per month waiting for builds. That's almost a full engineer doing nothing but watching a progress bar.
Show the trajectory
Slow code gets slower. If page load time has gone from 2 seconds to 4 seconds over the past year, show the trend line. Ask where it'll be in another year if nothing changes. Trajectory arguments are more compelling than snapshots.
Propose bounded work
Don't ask for a rewrite. Ask for a focused optimization sprint with clear targets: "Two weeks to get CI under 15 minutes and P95 response time under 500ms on the three most-trafficked endpoints." Bounded, measurable, achievable.
What optimization actually looks like
When we optimize a codebase, we don't rewrite everything. We profile, identify the highest-impact bottlenecks, and fix them in order of ROI. Typical wins include:
- Database query optimization — N+1 queries, missing indexes, and over-fetching account for most API slowness. Fixing these is usually straightforward and dramatic.
- Build pipeline restructuring — parallelizing test suites, caching dependencies, removing redundant steps. We've cut 45-minute pipelines to under 10.
- Memory and resource profiling — finding the one function that allocates 500MB per request, the connection pool that's sized for 5 users when you have 5,000.
- Dead code elimination — removing the code that nobody uses but everyone loads. We've seen bundle sizes drop 60% from this alone.
The pattern is always the same: a small number of things cause most of the pain. Find them, fix them, measure the improvement.
The real risk is doing nothing
Teams often frame optimization as risky — "what if we break something?" But the real risk is the status quo. Every month that passes with a slow, brittle codebase is a month of compounding costs: slower teams, frustrated engineers, degrading user experience, and mounting technical debt that gets harder to address the longer you wait.
"It works" is a starting point, not a finish line. If your code works but everything around it is slower, harder, and more fragile than it should be — that's not something to accept. That's something to fix.