"Deleting Code" Culture

When we talk about software improvement, we often talk about what we can add: new features, new tools, new abstractions. But sometimes, the most impactful thing you can do is delete code.

Hello, developers! 🚀

Welcome back to the Learn Agile Practices newsletter, your weekly dose of insights to power up your software development journey through Agile Technical Practices and Methodologies!5t

Before starting, I quickly remind you that my brand new Test-Driven Development 101 5-day Email Course is available: it is the introduction to TDD I wish I had when I started learning it, so I think you will find it very useful!

As a subscriber to my newsletter, you can have it with a 10EUR discount! 👇

Now, let's dive into today's micro-topic!

In short

🧹 Many teams equate productivity with writing more code, but high-performing teams know that the cleanest, most maintainable code is the one that doesn’t exist.

⚠️ Unused or outdated code becomes noise, introducing bugs and cognitive overhead. Instead of holding onto logic “just in case,” teams should evaluate whether it actively helps or hinders today’s goals—and delete accordingly.

🧠 As our understanding of the system improves, some code becomes obsolete. Smart teams integrate code removal into their workflows through cleanup sprints, thoughtful PRs, and a culture that celebrates subtraction as much as addition.

🛠️ Removing unnecessary code fosters a culture of continuous improvement and experimentation. The goal should always be to build the simplest system possible to satisfy our needs, and part of that simplicity comes from unwritten/deleted code.

The less code we have, the better

When we talk about software improvement, we often talk about what we can add: new features, new tools, new abstractions.

But sometimes, the most impactful thing you can do is delete code.

Not rewrite.
Not refactor.
Not comment out.
Just… delete. 🚮

It may sound counterintuitive—especially in cultures that associate productivity with producing more. But in reality, high-performing teams understand that less is more when it comes to code. The cleanest code is the code that doesn’t exist - and embracing a culture of code deletion accelerate development, reduce complexity, and keep your system agile and healthy.

---

🔍 Code Is a Liability, Not an Asset

Every line of code carries a cost.

It needs to be read, understood, maintained, tested, secured, and eventually replaced. Code that sits untouched for months becomes an unknown. Code that nobody uses becomes a trap. Code that was written “just in case” becomes technical debt before anyone realizes it.

And yet, many teams hesitate to delete anything—because someone might use it, or because “we spent so much time writing it.”

Face the truth: Unused or obsolete code slows you down.

It creates noise. It increases the cognitive load. It becomes a source of bugs, regressions, and fear. Instead of hoarding old logic “just in case,” we should ask: “Is this helping or hurting our ability to change this system today?”

If the answer isn’t a clear yes, it’s time to let it go.

Great engineers don’t just write elegant code—they remove everything that no longer serves a purpose.

---

🧠 Deletion as a Learning Practice

Deleting code isn’t a loss of knowledge. It’s a sign of learning.

When we first write a piece of software, we’re doing our best with the knowledge we have. As our understanding evolves, some of that early code becomes obsolete. That’s normal. That’s growth.

A good developer builds.
A great developer knows what to tear down.

In fact, making code deletion part of your regular rhythm helps build a culture of continuous improvement and safe experimentation:

• Use deletion as a natural part of refactoring—don’t just move code around, challenge whether it should exist.

• Document why you’re deleting something in your commit message or PR—this reinforces clarity.

• Run internal “deletion days” or “code cleanup sprints” focused purely on removing legacy code, unused features, and old abstractions.

• Celebrate deletion PRs the same way you celebrate feature PRs. Because they both move you forward.

As Dan North brilliantly puts it in The Best Simple System Money Can Buy, the goal is to build the simplest system that works—for now. That “for now” part is crucial: it means we’re allowed to evolve, simplify, and prune our system as we go. And deletion is how we stay lean enough to respond to change.

Until next time—happy coding! 🤓👩‍💻👨‍💻