Four ways to spend less time (and budget) fixing your application bugs.
Four ways to spend less time (and budget) fixing your application bugs.
Finding and fixing bugs is a critical part of the development process, both in development and production, but is it possible to be more effective in less time?
A poll of thousands of software industry members conducted by Stripe revealed that the average software development team spends up to 42% (Stripe/Harris) of their time on tasks in service of fixing bugs.
That's almost half of all developer time spent maintaining old code instead of writing new code.
Our team has a lot of experience helping developers spend less time and money fixing bugs (we build a crash reporting tool). Through our years of helping teams become more productive, we've observed four key areas where improvement dramatically decreases the time companies have to spend on fixing bugs in their support process
Teams need to focus on the following areas to spend less time and money fixing bugs:
- Create a system to find and fix bugs earlier in the development process
- Actively monitor deployed applications for bugs.
- Determine what to work on first based on user data
- More quickly understand defects without having to replicate the underlying issue.
We've repeatedly seen that teams who work on targeting these four points have seen a dramatic drop in their crash rates and overall time spent supporting their application.
#1 Create a system to find and fix bugs earlier in the development process
Shipping a new version is a lot like a moving train.
Ok, not exactly, but stay with me.
When a train is at or just leaving the station, it takes very little energy to stop its momentum. Fixing minor issues is easy because the train isn’t speeding down the tracks yet.
Once the train has left the station and is heading towards its destination (eg, getting shipped live), it takes a lot more force to stop or alter its progress. Any fixes must be done with the added stress and complexity associated with the train's velocity.
For similar reasons, bugs become more expensive and difficult to fix as a version of your application begins to pick up speed and head toward launch.
The more bugs a team can find and fix early in the development process, the less work and headaches they will find while testing later in the development process. That’s because fewer stakeholders and less complexity are built on top of the underlying error; getting a bug fixed early and worked out early is one of the most efficient ways to decrease your support workload.
Creating and implementing a workflow to automatically find, triage, and fix bugs early is a powerful tool for decreasing the amount of time and effort your team has to spend shipping new versions.
Our users do this by integrating BugSplat early in the development process, allowing for automated crash and error reporting from the beginning. When a new crash happens in development, the critical details about the underlying defect are uploaded to BugSplat, where it can be quickly turned into an issue logging in to your favorite bug tracking tool, where it can be assigned and fixed fast.
Using this process helps teams identify and fix issues throughout the development process instead of only when the version is closer to being shipped.
#2 Actively monitor deployed applications for bugs.
This could also be labeled ‘don't wait for user complaints’ or ‘don’t have 15 platform individual tools for monitoring’.
Too often, teams ship without a practical system in place to track performance, report stability, and identify critical defects before they become a big problem for users.
This leads to scenarios where teams learn about issues in their code from users complaining about it via a support email, on Twitter, or somewhere else online.
A general rule of thumb for support is that if 'X' number of users go out of their way to report the problem, 100 users have already experienced it and been frustrated with the problem. Hearing about an issue means it’s already too late to nip the problem in the bud. Responding to user complaints and support issues around the bug presents a real drag on team time, increasing the support work associated with bugs.
To stay ahead of issues, you can’t wait for them to come to you, and you need to implement a system that provides early warnings for issues.
Unfortunately, for many teams, this means using a patchwork of tools to monitor across all deployed environments. This leads to precisely this kind of scenario because it makes the task of checking on issues time-consuming and difficult.
Which means it doesn’t always get done.
What we’ve seen is that teams get the full benefit of monitoring when all of their crash reports are accessible via just one tool - not a patchwork of hard-to-use tools covering a single deployment.
We often hear that users weren’t checking performance or setting up key alerts because of how many tools they used. With BugSplat, they can have their reports all in a single tool (with useful alerts), which saves them a lot of time.
#3 Effectively identify and resolve highest-priority issues
Not all bugs are created equally, and knowing which bugs to focus on can have a significant impact on productivity and the success of support.
Not all bugs are created equally, and not all bugs must be fixed to support a stable product that its users love.
The trick is to create a process that allows your team to evaluate bugs effectively and identify the ones that are most critical to fix.
Without a tool like BugSplat tracking crashes and errors, teams can guess which issues are essential to fix that they discover—or get reported via email, forums, and Twitter users. Nobody knows their codebase like the team that built it, so there's a built-in advantage many teams rely on to determine if a discovered issue is critical to fix.
However, without an automated way of capturing all crashes—and evaluating the severity of the defects based on the total frequency and the overall number of users affected—teams often have to make gut choices on what to fix.
With BugSplat, teams can use the intimate understanding of their own application with comprehensive data on application defects to ensure they are fixing their most critical bugs first and not missing a key defect entirely.
Adding this to the development and support process quickly decreases bugs, improves stability, and makes teams more efficient.
#4 Skip having to replicate defects
A significant portion of the support process involves replicating, triaging, and diagnosing issues once they're discovered. The traditional approach to bug fixing often involves spending countless hours replicating issues locally, which can be time-consuming and frustrating. Developers may spend hours or even days trying to reproduce the exact circumstances that led to a crash or error, only to find that the issue is intermittent or difficult to pinpoint. This approach can result in a backlog of bugs that need to be addressed, causing delays and impacting the software's quality.
With a tool like BugSplat, developers can streamline their workflow and save time by quickly identifying and fixing issues without the need for time-consuming replication. BugSplat automatically collects all relevant crash data, including the stack trace, environment variables, and user data, and presents it in an easy-to-read format. This allows developers to see exactly what went wrong and quickly identify the root cause of the problem, giving them the context for the crash without having to recreate it themselves.
When teams have a large amount of crash and error data in a central repository like BugSplat, all team members can access the same information and work together to resolve issues quickly and efficiently. This means they can spend less time on manual tasks and more time implementing real fixes, resulting in higher-quality code and a better end product for the user.
For many teams, the cost of supporting unstable code, fixing bugs, and maintaining applications is much more than 42% of the total development time. The actual cost extends far past this time investment and can only be accurately measured by considering the lost opportunities a company gives up by dedicating so much time and effort to fixing bugs.
By adding BugSplat to the support and development process, teams can dramatically decrease the time that their developers spend finding and fixing their bugs. They can find bugs earlier in the development process, decrease the time needed to fix them overall, and monitor their code to ensure that it is stable and that no unknown bugs are causing issues. They can also prioritize which bugs to fix using a complete picture of their application's stability and known defects' impact before resolving known issues faster when BugSplat removes the need to replicate and triage bugs.
Combined, we see how teams that integrate BugSplat into an existing application dramatically cut the time they take to support their application. This allows them to prioritize other, more valuable business and development goals.
Interested in trying out BugSplat for yourself? Sign up for free here 👉 https://app.bugsplat.com/v2/sign-up