Why you should delete code every sprint

Codebases and resource usage grow by accretion – we tack on new features, expand code to support new requirements and run scenario tests. Every now and then, we pay off some tech debt (if we’re lucky). 

What is more likely though is that we keep adding code and resources day in day out. Eventually, days stretch into weeks and weeks in turn, stretch into months.

Then, one day, there is a big ball of code that no one seems to understand what it does or how it works. Another symptom of this is having a huge cloud bill due to the proliferation of test resources. Worse still, no one seems to know how the situation degenerated so badly over the years.



Do you remember the clothes you wore 10 years back? Where are they right now? What would happen if you never deleted gave out old clothes?

If you never threw anything out then your house will eventually fill up with unwanted junk. Most of us continuously clean out our homes and throw away things to avoid this. Thus the question is why don’t we do the same thing for code, resources and repositories?

Code becomes bloated, computing resources become disused and repositories go stale. Yet, we ignore the ‘dirt’ until it becomes a blocker despite the confusion and wasted efforts caused by developers going down the wrong path.

A better approach will be to schedule clean-ups into the sprint/iteration. This will help to prevent the quality atrophy due to entropy caused by software complexity.

Ideas for a Fix? 

One experiment I want to run with my squad is to factor in code/resource clean up into our sprints. A sprint will not be considered completed unless something (no matter how minute) got deleted.

I love deleting code/artifacts so much because:

  • Deleted code can’t cause bugs (biggest win!)
  • You don’t have to debug deleted code – saves you from bloat and cognitive loads
  • Encourages simplicity and teaches people to keep the codebase clean and lean
  • Keeps running costs low

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Antoine de Saint-Exupery

How is different from Refactoring?

Scheduled cleaning shares a common goal with refactoring because they both aim to make code easier to work it. But it differs a bit because it is not limited to code alone; cleaning covers aspects like artifacts, compute resources and repositories.

Now, go ahead and schedule clean-ups into your process.

Leave a Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.