WTF Thursday (aka Bug Squashing Day)

Last Thursday was the first WTF Thursday at DNSimple. If you are asking yourself what the heck is a WTF Thursday, then just keep reading.

All started during our recent team retreat in Avignon. During the quarterly state discussion, Anthony reported his frustration with certain recurring issues with our sales order system that cause him to manually fix stuck orders every once in a while. So, what are we supposed to do to fix this problem?, he asked.

A short digression. The state of the bugs in our system has always been a major focus and concern of mine. I've always stressed that everybody in the company should review the bug list from time to time to make sure the number stays under control. There are rumors that I was hired to fix the code that Anthony was building.

If you ask Steve — our friendly chat robot — for a quote, one of his favourites (actually the only one so far) is the following:

I make it work. Someone else makes it right.

Guess who said that!

Back to the original topic, the most voted proposal to the question was to establish a bug squashing day.

How does it work?

The goal of the day is that everybody in the company should pause what they're working on for a day and work solely on debugging/fixing reported bugs. Since it was the first time we've ever tried something like that, we decided to go with a small, simple list of rules:

1. Everybody in the company MUST participate.
2. No new features.
3. You pick a bug you want to work on, ideally something that has an impact on our customers, and you work on it.
4. You have to deliver something (either ship some code or produce some tangible results).
5. Any DNSimple repository is part of the game.

First of all, it is important that everybody in the company participates in the bug squashing day. This is one of the key reasons we decided to dedicate a specific day, rather going with other alternatives. Since we work remotely, team members have different habits, time zones, and needs. In order to be as effective as possible, it's essential that anybody in the team is free to ping anybody else for a peer review or feedback, without being worried that the other team member is working on something important or, even worse, is not available.

We don't want to introduce new features on our squashing days, as new features can introduce new bugs. We also decided to not set any contraints on the type of bug a team member can work on. You can work alone or pair with any other member. In any case, the code must be peer-reviewed (as part of our normal shipping policy) before being released.

Ideally, we were to work on a bug that has an impact on our customers, rather than an internal issue. That's because internal bugs have higher chance to be fixed at some point (as we are annoyed by them) whereas public facing bugs may live longer.

Another key point is that everyone must deliver some value by the end of the day. In other words, multi-day bugs are not valid. If the bug is big enough that it can't be fixed by the end of the day, we split it into smaller steps and work on one of them.

There are several reasons behind this policy. If you work remotely, it's important that you learn how to sandbox your time in order to be effective and prevent a problem from sucking up all of your effort and energy. Moreover, delivering something provides that instant gratification keeps you motivated even if you are working on a potentially boring task like bugfixing.

Shipping something also makes it possible to measure progress, even if it's merely counting the number of closed tickets.

As mentioned, we didn't restrict the game to a specific repository. That's because each repo can have bugs: the application can have bugs, the documentation can have typos, the chef cookbooks can format a server disk by mistake.

WTF?

There are two questions I haven't answered yet: how did it go and why wtf?

I don't recall exactly how WTF entered the scene. However, it happened and we decided to name this event our WTF day. We then came with a proper explanation of the acronym:

The WTF day was then renamed WTF Thursday as… it was the only day in the previous week where nobody on the team had a scheduled appointment for the day. That's how WTF Thursday was born!

The results

These are the results of our first WTF Thursday: 5 authors have pushed 22 commits to master and closed 17 issues. Of course, Anthony broke the rules and opened a new issue (discovered by me, but the ticket has his name hence we can all blame him).

To be fair, this chart doesn't reflect the changes (hence contributions) to other repositories such as our chef repositories, the Jekyll static sites, etc.

Among these 17 issues, at least half of them where invalid tickets that were sitting there. Which may happen as such: we open a ticket in response to a customer report, the affected feature then is refactored/changed/removed, and the issue stays there. Even if it doesn't directly involves any coding, closing invalid tickets is a great way to reduce the noise in the issue tracker and make sure real bugs stand out.

We definitely call this day a success and we have already planned the next WTF day for the coming two weeks… of course, on a Thursday! Let us know if you have any feedback or questions about this idea!

As a side note… WTF is also a new gTLD and we provide both WTF domain registration and transfer, just in case you want to register your team.wtf domain name.

Share on Twitter and Facebook

Simone Carletti

Italian software developer, a PADI scuba instructor and a former professional sommelier. I make awesome code and troll Anthony for fun and profit.