Our First Fixathon: How We Squashed 44 Bugs in One Week
Software Engineer at Buffer
Buffer, as a company, closes the last week of the year every year, and historically, as an engineering team, we’d do a code freeze for the week before we’re closed so nothing broke heading into the holidays. (Pretty smart of us.)
This year, we did something different, and it still worked out. We used the last week of the year as a “fixathon” for our whole engineering team.
Fixathon = a week where our 29-person engineering team spent a whole week focused on fixing bugs.
By the end of the week, not only had we fixed 44 bugs, we also didn’t break anything in the process. 😎
Here’s more about our process for setting up the Fixathon and the outcomes.
Why we spent a week on bug fixes
Like any product, there are bugs in Buffer. We come across them, our Advocacy team notices them, and our customers flag them. We believe that making these seemingly small improvements while resolving bugs can ultimately have a huge impact on the user experience, which is a big goal for our team at the moment. But this week wasn’t just about bug fixes — this was about taking an opportunity to bring the whole engineering team together to improve how we work. We spent a week building better habits around releasing changes, improving our communication, and collaborating more closely with our Customer Advocacy team and each other.
How Fixathon worked
Ahead of the Fixathon, we crafted a list of tasks for our team to work on quite carefully to ensure the risk of outages was as small as possible. From there, we wrote up a set of guidelines for all of our engineers to jump right in once the Fixathon started.
To start, we opened up a tool called Bugsnag
Each day started with our engineers engaging in Bugsnag, a tool designed for monitoring and managing automated error reports. The primary objective during this phase was to triage these automated error reports. Our team reviewed, categorized, and, where possible, resolved issues directly reported by Bugsnag, and our goal was to perform an action on at least 15 bug reports before moving to the next phase. This process was essential for understanding the state of our systems and possible problems in them - especially since we were guilty of not doing that on an ongoing basis earlier.
Next, we switched to product bug reports and resolved them
After the morning spent triaging Bugsnag reports, our engineers shifted their focus to the product bugs some of them pre-selected earlier with the help from the product team. These were issues previously identified and logged in Jira. Engineers selected tasks in the areas they were familiar with and made sure to work on them safely, reviewing each other code and double-checking everything was done in a proper way to avoid any issues in this sensitive time.
We then kept the Advocacy team in the loop
A big part of the Fixathon was making sure our Advocacy team was aware of the changes we were making. We posted daily messages into an updates channel with a roundup of the previous day’s fixes.
We spent the last day of Fixathon on quality assurance (QA)
Instead of making more changes on the last day of the year before closing for the holiday season, we spent a day making sure we were leaving things in a good state with some QA. We were going through our product and making sure everything works as expected, spent some time together in the calls to catch up, and just have a jolly ol’ time.
The results of our first Fixathon
Ultimately, we learned a ton by doing a Fixathon. We learned how to better operate in Bugsnag as a team to reduce the numbers, we got better at collaborating with each other and Advocacy, and we gained visibility into many issues that otherwise would go unnoticed. We’re hoping this process stays with us, and we will clear new Bugsnag issues on an ongoing basis, making it easier for us to manage our bugs and notice them before our customers can do it!
The other part of Fixathon was fixing actual bugs! We resolved 44 tasks total, many of them small bugs we didn’t have time for earlier in the year. While most of them were so small that it’s hard to notice the change individually, all of them contribute to our vision of a consumer-grade experience.
A few notable bugs we squashed included:
- Adding a billing page link to the account settings dropdown
- Making “suggested media” scrollable
- Lots of styling changes to make our margins and appearance consistent throughout the product
As a part of the Fixathon, we’re also close to releasing the “first comment” functionality for LinkedIn, which we already have for Instagram. (Join our beta program to get first access.)
We crafted the list of tasks to work through quite carefully to ensure the risk of outages was as small as possible. And what’s most important - we delivered; there were no Fixathon-related incidents in the past weeks!
We consider Fixathon a pretty successful initiative, and though it’s the first time it has happened, we hope it’s not the last one! We squashed bugs, spent some time together, and learned cool things. And what’s most important - we improved our product as a result!
Try Buffer for free
140,000+ small businesses like yours use Buffer to build their brand on social media every month
Get started nowRelated Articles
Nine years ago, we decided to launch a new free product alongside Buffer. We called it Pablo, and it was a huge hit in our community. Within just seven months of its launch, half a million photos were created using Pablo. Similarly, we had the initial ideas for Stories Creator and Remix many years ago now. All three of these tools have been an important part of Buffer’s story. They’ve taught us lessons and helped us connect with a wider audience. In Pablo’s case, the idea for this tool happene
If you use Buffer, you might have experienced us having more downtime than usual recently. We want to start with an apology for not sharing more transparently along the way what’s been happening. We’ve been caught up in the work and haven’t invested enough in communicating with our community, and we’re so sorry about this misstep. We know some of our customers have had a frustrating time using Buffer recently and we need to do better by you. This past August and September were the months we’ve
As part of our commitment to transparency and building in public, Buffer engineer Joe Birch shares how we’re doing this for our own GraphQL API via the use of GitHub Actions.