Ostorlab's Fix it! practice is one of our most successful engineering practices. It is a competition-style event that lasts for one to two weeks, where team members compete to fix as many bugs as possible.

While participating to Fix it! is usually optional, at Ostorlab, we ensure that the entire team participates. This demonstrates our commitment to working as a team and ensuring that our work is as bug-free as possible.

To provide more context on why we use this practice, at Ostorlab, we typically operate in project mode, forming squads of 2 to 8 people to work on features, major bug fixes, or technical debt removal. Although bugs and issues that have a severe impact are typically addressed immediately, many smaller annoyances do not make it to the top of the bucket list. Fix it! helps address this by tagging all issues that do not qualify for immediate fixes as fixit!

If you are interested in applying the same concept within your team, here are some lessons learnt:

• Duration: The duration of Fix it! has varied from one to two weeks, with longer periods becoming too overwhelming, one week being too short. Fixing bugs can be nerve-wracking, so ensuring that the time allotted is reasonable is crucial.

• Tracking: Additionally, during the event, we use an internal platform to track fixes and show a leaderboard to track progress over time, which makes it fun and challenges everyone to do their best.

• Point System: It is important to treat all bugs equally and avoid creating a point system for bugs. This helps remove arguments over whether certain bugs are worth more or less and keeps things simple. As a result, easy bugs are usually cleared first, leaving only the harder ones towards the end. During the Fix it! event, new bugs may be discovered before or during the fix. For example, in our last Fix it!, we started with 161 bugs, cleared 142, and were left with 132. While the math doesn't add up, this helps us test the platform exhaustively and identify usability quirks that we can address while fixing the bugs.

• Code Review: Because the incentive system of fix it, which focuses on fixing as many bugs as possible, code quality will often be a second thought. Having a strong CI/CD pipeline with linting, type checking, unit test coverage and proper code review process is crucial to avoid introducing more bugs than you are fixing.

• Weekend: If Fix it! lasts for more than a week, we make sure that there are no weekend fixes. This ensures that everyone is on the same page and has a chance to enjoy their personal time without feeling obligated to work.

• Closure: At the end of Fix it!, we share the results and discuss ways to improve it further. We also highlight some interesting aspects, such as the coolest bug to fix or the unexpectedly hard one. We also share our lessons learned, which help guide future technical stack decisions or system design choices. By sharing our experiences, we can identify areas where we can improve our processes and avoid similar issues in the future. This helps us continuously enhance the quality of our work and ensure that our systems are more robust and reliable.