How we deleted 4195 code files in 9 hours

Like a Hackathon, but with a twist. Template included!

“Let’s keep that code - just in case, for backward compatibility”

How often did you hear this?

Turns out, it’s very common! Most of the existing code is not used (70% of JavaScript functions on average web pages are unused).

Today I’m going to share with you a very simple (and fun) way to get rid of that old and unused code.

---

2 months ago, I was reading this great article by

Gergely Orosz

from

The Pragmatic Engineer

, on organizing a GenAI Hackathon. I decided to organize one in my company. It was the 4th I was organizing, so I was a bit sick of the usual business-oriented ones and decided to go with something new.

The GenAI idea was ruled out (I’m going to organize a GenAI one later this year!), and my manager suggested an interesting idea - let’s clean up our codebase! We’ll stage a competition with worthy prizes, and in a single day delete all those unused files we always dreamt of cleaning up.

Behold - the Cleanathon!

Or as some people mocked me - Cleananton 🤦‍♂️

It turned out to be an AMAZING idea.

So today I’m going to share how you can easily do the same! I’ll cover:

• The goals of a Cleanathon

• Some statistics

• What to consider when organizing the event

  • Scoring system

  • Stability

  • Creating excitement

Organizing a cross-department event is one of the best ways to become visible, which is very useful for those seeking the management promotion. So aside from the great benefit to the company, you’ll also benefit from this event - it is definitely worth the effort in my opinion.

If you want to organize one, you can use the free template I created in this Google Doc:

The goals of the Cleanathon

It started as a simple competition - each team needs to delete as much unused code as they can. The best team wins personal prizes.

Then we decided to make it a company-wide event, and involve all departments. This made it very hard to score the competition (tips below), but for the first time, everyone could truly participate in a Hackathon.

Our 3 main goals were:

1. Have a fun, company-wide event.

2. Clean up your work environment the best you can.

3. Do it without breaking production…

Some statistics

Participation

We had 9 teams participating, with 3-4 members each:

• 3 development teams

• AI team

• Technical support team

• QA team

• The Product & design team

• The Finance team

• DevOps + architects team

Partial results:

These are just the top 10 stats, many more things were deleted & organized!

1. We saved thousands of dollars in monthly payments

2. We deleted 4195 files in our code, and additional 4747 code lines

3. We closed 120 open PRs and deleted 2851 unused branches

4. We deleted 22 feature flags, and removed 46 packages from dependencies 

5. We deleted 42 Jenkins jobs and 58 kubeflow pipelines

6. We archived 50 repositories

7. We deleted 63 old tables.

8. We deleted & organized 47,804 files in Google Drive

9. We deleted 159 old confluence documents and Archived 200 Jira tickets

10. We deleted 6 Figma files and 40 Jira Automation Rules.

What to consider when organizing the event

Start with the simple things:

• Which teams participate?

  • in our case - every team that wanted

• How much time do you allocate to the event

  • We chose a single working day, unlike the regular 24-hour Hackathons, and I think it was a good decision.

• Are the teams mixed?

  • We decided to do the competition in the organic teams, as it was important to us that each deletion is reviewed by people from the same business domain, to reduce risk.

Then you can continue with the more complex task, of making sure it will be a fair & fun competition, that will not impact customers.

⚠️⚠️⚠️ Stability ⚠️⚠️⚠️

We came up with 4 simple guidelines:

• PRs: Every pull request must receive 2 approvals from people familiar with the relevant codebase. The PRs will be left open.

• Special Branches: Dedicated branches will be created in big repos, and all PRs should be merged into them. 

• Testing: Every developer should responsibly test their changes.

• Post-event, a full Cypress end-to-end test run will be performed using all the branches, to ensure stability before the official release.

The day after the event, you need to make sure that all the PRs are tested together in a single environment, and merged.

We have a solid QA environment and test coverage, so we caught all the problems (2-3 in total) without any impact on our customers.

Creating excitement 🕺🏻

Such events are much more successful if you add some fun touches to it. I guess it largely depends on the company’s vibe, but I’m sure there are some things you can do even in a very serious place.

I went with generating names and logos for the 9 participating teams:

I also decided to create a small A4 page with the names, logo, and photos of all team members, which I printed and hung on their office door:

This is very specific to the small amount of teams, and in-office work environment we have. If you want some ideas for your company’s use case, write a comment and we’ll figure something out :)

Why should you provide a scoring system?

This was a HUGE pain-in-the-ass for me - especially when we decided to open the competition to non-development teams. It’s VERY HARD to come up with a fair scoring system - and an unfair one can ruin the event.

I still think that providing scoring for the contest is absolutely critical for the success of the event! As it was very hard to compare different teams, there was a suggestion to let people present at the end, and decide the winner by a vote.

I think this would have ruined a lot of the fun. With the scoring, the atmosphere was electric! People worked until the very last moment, and there was a close match between the first 3 teams.

Creating a scoring system

I hope my tips will save you some headaches, but be prepared to answer scoring questions all day and deal with super-competitive people who try to bend the rules…

My approach was as follows:

I wanted the average score to be 10,000 points per team. So when talking to people from different roles, I asked them to estimate how long a task takes, and how much will they be able to do in a day.

• I estimated a coding team will delete 100 files and 5000 additional lines of code (big miss here)

• The DevOps team will save $1000 monthly dollars

• The finance team will delete 10000 files in Google Drive (47K were deleted during the event!)

And so on.

The most critical addition to the scoring system was added a day before the event: In all categories, I added a 1000-point limit per action. 

So if you deleted 50 files in one folder, it’s 1000 points (and not 5000).
If you delete more than 1000 lines in a single file - it’s 1000 points. 
If you save monthly $150 by deleting a VM, it’s 1000 points (and not 1500).

Defining an action was very hard, so basically I judged it case by case…

The first 3 places were with 26K, 23K, and 17K points, so it was a close competition.

You can find the detailed breakdown we used in the template Google Doc I created here. It covers code changes, money-saved points, Jira cleanup, and many more categories. You can just copy (file → copy) and reuse it.

How to track the scores

I appointed a leader in each team, who was responsible for tracking the changes and the points of each change. You must make sure the work is documented if you want a fair competition.

If you have the time for it, I suggest creating a template people can use - in our case each team using a different spreadsheet and it was a bit of a mess.

Finally - the total score of each team was divided by the number of participating team members.

Final words

Competition is a great thing - it adds a lot of fun to an activity that most developers would consider boring on a good day (and awful on a bad one).

The hard part is to remind people that our goal here is to help ourselves in the long term - increase the efficiency and clarity in the critical systems for your team. If you won’t re-iterate that, you risk people just going of to random old repos to delete code - while the point is to clean up the most important ones.

In addition, you should think of the second-order consequences (great article by

Michał Poczwardowski

). In the 2 weeks before the Cleanathon, nobody deleted anything, and saved it for extra points… There is a reason some people think that technical debt Hackathons are a waste of time. You should encourage continuous cleaning up of your codebases - someone even suggested a reward for the team in the last place, which had the least to clean up :)

To wrap it up - it was one of the best events I organized, try it out!

Edit: how to prevent the same mess from accumulating

In the comments, Serhii made a good point: “WTF? So you’re telling me that there were nine departments, each with 3-4 members, and no one seemed to care about this mess until a competition came along?”

My answer is that it’s very hard to prevent such a situation from happening in the first place, especially in small and fast-growing startups. There is always something more urgent than cleaning up.

The key is to make sure you don’t fall into the same trap TWICE. So if you do a Cleanathon, use the opportunity to create guidelines. Some of our additions were:

• We changed policies to automatically delete merged branches.

• We added dead code analyzers that will help us identify dead code in the future.

• We do a weekly analysis of the cloud costs, quickly killing any anomalies and cleaning up unused resources.

• When we create a feature flag, we also create a ticket to delete it, putting it in the relevant sprint (usually a couple of weeks after the release).