Flawless code doesn’t exist: why all bugs aren’t worth fixing 2022

While engineering teams do want to ensure proper quality testing is in place before rolling out a new feature, there are some errors that are okay to be left in the code when it is shipped, it’s just a matter of prioritizing the right ones. In fact, the best engineering teams in the world know that not all bugs are worth fixing. 

So how do software engineers determine which bugs to leave and which to prioritize fixing when under tight deadlines? The key is being able to quickly determine the minor glitches from the egregious bugs that could damage the user experience and ultimately your app’s reputation.  

Below are three key steps for mastering the error monitoring and bug prioritization process when it’s impossible for engineering teams to address everything at once. 

1) Adopt a progressive delivery approach

Historically, engineers would write the code and send it off to the quality assurance (QA) team to sift through to identify any errors. They would then roll out a new user interface (UI) for the app or website and after that, monitor the user experience and fix bugs after they’ve already impacted the whole user base. This type of traditional app delivery makes it impossible for developers to execute faster app releases without resulting in more coding errors, but progressive delivery is designed specifically to support this rapid pace.

Progressive delivery is a method of software development that allows organizations to release updated apps rapidly while maintaining quality and preventing bugs from wreaking havoc on the user experience. There are several strategies that go into a successful progressive delivery program. By embracing phased rollouts, feature flagging, and experimentation, engineering teams can support faster releases and better app quality than traditional app delivery strategies. 

Phased Rollouts: New features and software updates are first released to only a select segment of users before being rolled out to broader audiences. This allows engineers to optimize the app while catching and fixing bugs before they impact the entire user base. In turn, it enables developers to release smaller and more frequent app updates so users can experience new features quicker without exposing most of them to bugs.

Feature Flags: These are used to turn certain features on or off for a subset of users and return to a previous codebase. By monitoring the impact of new features to this smaller subset, engineering teams can significantly reduce risk by shutting off bug-prone releases before they create too much disruption. 

Experimentation Tests: Tests how different features perform when an app is in production. This can be simple A/B testing, or it can contain multiple variants so the variant which has the best impact can be selected.

2) Prioritize code ownership to improve team alignment while debugging

Code ownership is a strategy engineering teams can use to prevent wasting time and resources by having multiple teams sift through code searching for the route of the same error. Without code ownership in place, traditional error monitoring alerts the entire engineering team when an error occurs, regardless of whether or not they had worked on that project. This creates ambiguous ownership for remediation and can cause significantly longer downtime. 

With code ownership, the only team that’s notified of a bug is the one responsible for the part of the code where a bug originates. By offering a quicker and easier approach, code ownership eliminates the confusion and guesswork associated with the process of debugging, allowing engineering teams to easily identify, own, prioritize and remedy bugs. Plus, code ownership expedites debugging efforts and has a pronounced positive impact on stability. Embracing code ownership is critical to improving app stability, which is the most fundamental measure of an app’s health.

3) Streamline error prioritization by focusing on the fixes that matter and snooze the rest

While engineering teams across all organizations differ greatly in their structure and internal processes, any team that is monitoring software stability will benefit from streamlining its error triaging practices. At a high level, triaging bugs involves reviewing the errors currently affecting your system and sorting these errors into three general categories.

• Errors that need immediate developer action (rolling back a release, deploying a fix, etc.)
• Errors that do not need immediate action at the moment, but may in the future (if the error becomes more frequent, affects more users, etc.)
• Errors that will never need developer action and can be ignored safely

During triage, it’s not uncommon to review errors that are relatively low impact and don’t need to be fixed with any immediate urgency. In these situations, the key question to ask is, “what would need to change about this error’s impact for us to prioritize a fix?” 

Often the answer to this question will involve an absolute number of additional occurrences of the error, a frequency of occurrences over some time period, or a time in the future after which the error is no longer expected to occur. In all of these cases, these criteria can be expressed using a snooze rule. Snooze rules are great for keeping up with errors that are initially low impact but may become more severe in the future. Once you’ve snoozed an error, it will only return to the “for review” state if the snooze threshold you specified is reached. At this point, it’s often worth prioritizing a fix.

Keep calm and code on 

With today’s booming app economy, consumers depend on using applications more than ever, and expectations are high for software engineering teams to quickly ship out new features. End-users simply have little patience for apps that crash or fail and app stability is a fundamental part of every app experience.

However, engineering teams need not panic. The goal should never be “flawless code,” but rather a focus on application health and stability. With the right software delivery approach, code ownership and bug prioritization, engineering teams can use their time more efficiently on urgent fixes and maintain stellar app stability for users, despite any bugs in their code. Due to these reasons, it’s no surprise that app stability is closely tied to customer retention, customer growth and revenue.