I deleted 4,000 lines of code last Tuesday. It was the most productive day I've had in months.
No new features. No refactoring. Just removal. And the codebase got better — faster builds, fewer flaky tests, easier onboarding for new devs.
We celebrate writing code. We should celebrate deleting it.
Every Line Is a Liability
Code isn't an asset. It's a liability that sometimes produces value. Every line you keep is a line that can break, a line someone has to read, a line that slows down your test suite, a line that might contain a security vulnerability.
The best codebase isn't the one with the most features. It's the one where every remaining line earns its place.
Bill Gates reportedly said he measures programmer productivity by lines of code — negative lines. Whether he actually said it or not, the principle holds. Senior engineers obsess over reducing code for a reason.
What to Delete Right Now
Commented-out code. It's in git. You can always get it back. Commented code is visual noise that makes real code harder to read. I've seen files where half the lines are comments from 2021 that nobody will ever uncomment. Delete them.
Dead features. That A/B test from last quarter that lost? The admin panel nobody uses? The CSV export that three people requested and zero people use? Kill them. Each one carries maintenance cost, test coverage overhead, and cognitive load.
Abstractions nobody needed. That factory-builder-strategy pattern for a thing that has exactly one implementation? Replace it with the implementation. You can always add the abstraction back when you actually need it. YAGNI isn't just a cute acronym.
Duplicate logic. Two functions that do almost the same thing, written by different people who didn't know the other existed. Consolidate them. Then delete the duplicate.
Stale tests. Tests that test removed features. Tests that pass regardless of what the code does. Tests that take 30 seconds to run and validate nothing meaningful. They slow your CI and create false confidence.
The Emotional Barrier
Deleting code feels wrong. Someone spent time writing it. Maybe you did. There's a sunk cost fallacy baked into every line — "I can't delete this, it took a week to build."
But keeping bad code doesn't honor the effort. It punishes everyone who touches the codebase afterward. The respectful thing is to let it go.
I've found it helps to frame deletion as a feature. "Today I'm shipping the 'faster build times' feature" sounds better than "today I'm deleting stuff." Same outcome, different framing.
How to Delete Safely
- Check usage first. Search the codebase for references. Check analytics for feature usage. Ask the team if anyone relies on it.
- Delete behind a feature flag. For scary deletions, flag them off first. Run it for a sprint. If nothing breaks, remove the flag and the code.
- Small PRs. Don't delete 10,000 lines in one commit. Remove one module at a time. Your reviewers will thank you and your rollbacks stay surgical.
- Trust git. The code isn't gone. It's in the history. You can always bring it back. This knowledge makes deletion feel reversible — because it is.
The Compounding Effect
Deletion compounds. Remove 500 lines and your builds get slightly faster. Your IDE gets slightly more responsive. New developers onboard slightly quicker. Code reviews are slightly easier.
Multiply "slightly" across every developer, every day, for a year. That's not slight anymore.
The companies with the healthiest codebases aren't the ones that write the most code. They're the ones that delete relentlessly. Every sprint, every review, asking: does this still earn its place?
I challenge you: open your codebase right now and find 100 lines you can delete without breaking anything. I bet you can find 500.
Top comments (0)