We love bugs (and you should, too!)

OK, maybe "love" is a bit strong. But the Aha! engineering team has a shocking confession: We embrace bugs in our software. Our CTO, Dr. Chris Waters, often says, "If your feature ships without any bugs, you waited too long to ship it."

Having worked at software organizations of all sizes, many engineers on our team find this approach refreshingly unique. We don't view bugs as productivity-killing backlog items. Instead, we see them as a natural byproduct of focusing on what truly matters: delivering value quickly.

Although we certainly don't want our customers to experience bugs, we recognize them as opportunities. Each support escalation becomes another chance to interact with our users, understand their needs, and ultimately, deliver a lovable Complete Product Experience.

Now, you might be wondering how we manage to maintain this seemingly counterintuitive approach while still keeping our customers happy. We'll dive into more reasoning behind our bug-welcoming culture next. But we'll also explore the unconventional strategies that make our bug-handling process not just effective, but transformative for our product and user relationships.

What is a bug?

Our approach to shipping code might sound bold, so it's important to clarify what we mean by "bugs." We strictly adhere to ISO 27001 security standards and enforce rigorous processes around data integrity and customer security. Any code change that compromises customer data security wouldn't simply be a bug. It would be classified as an incident, triggering a specific response protocol in turn. Our structured security review process thoroughly assesses each code change to ensure customer data remains safe and confidential every time we deploy. Security concerns are always handled proactively before the code is merged into the main application.

With this in mind, the bugs we're discussing here are related to functionality gaps stemming from undefined expectations within feature-rich environments. Our product's customization capabilities allow for diverse use cases. And even though we plan for and test the most common scenarios, there might be rare, complex cases we didn't anticipate during development. These cases might produce unexpected results, which we classify as bugs. Fortunately, exceptions are rare thanks to extensive testing and planning, and even less-common paths generally perform as expected.

The audacious claims

At first glance, our approach to bugs and product releases might sound unconventional, and maybe even a little reckless. But each of these strategies is intentional — grounded in our commitment to deliver quickly, address actual user needs, and improve constantly. Here are a few of our guiding principles:

1. We promote rapid releases and encourage the fastest possible delivery.
2. We focus on delivering 99% of the value rather than chasing the final 1%.
3. We see support escalations as prime opportunities for meaningful user engagement.
4. We keep a lean bug backlog (currently just 17).

These practices might seem counterintuitive, but stick with us. We'll show you how this approach has not only been effective for our development process, but has also strengthened our relationships with customers and improved the product.

Embracing imperfection

First, we don't aim for perfection. We aim for progress. Bugs will inevitably occur when dozens of engineers create complex solutions. As you work to create perfect solutions to every possible scenario in your code, the value of the task diminishes. The time it takes to reach that perfection adds to the time your customers have to wait for the functionality. Moreover, accounting upfront for every unlikely, but theoretically possible bug scenario compounds complexity across the board. The trade-offs of longer CI pipelines, increasingly complex test setups, and manual QA requirements slow us down, taking time away from direct value creation.

Instead, we're pragmatic: If you wait until your software is bug-free, you've waited too long. By focusing on getting functional changes out to the majority of our users quickly, we ensure that we're constantly improving and evolving our product.

The 99/1 rule

At Aha!, we've embraced what we call the "99/1 rule" in our development process. This principle isn't about ignoring the minority — it's about maximizing impact and efficiency. We prioritize features and fixes that benefit 99% of our users over edge cases that might affect only 1%.

Our approach is straightforward: We focus on the primary benefit of each feature and strive to deliver that value as quickly as possible. Once we've achieved the core functionality, we address our known use cases. However, we consciously steer clear of deep dives into hypothetical "what-if" scenarios about how a user might interact with a feature. These speculative discussions often lead to diminishing returns and delayed releases.

But what about that 1% we've set aside? Rest assured that we don't ignore them. Instead, we address their needs as they arise through our responsive support system. Our approach allows us to understand the real-world impact of these edge cases and prioritize fixes based on actual user experiences rather than hypothetical scenarios. Plus, getting feedback about bugs validates that the features we built are used and appreciated despite their imperfections.

By adhering to the 99/1 rule, we maintain our agility, keep our development cycles short, and ensure our product evolves continuously to meet the needs of our user base as a whole. It's a crucial element of our strategy to deliver maximum value in minimum time. This allows us to stay responsive to our users' most pressing needs while continuously improving our product.

Responsive support

A system like ours requires exceptionally responsive support to meet customer needs. This is where our secret weapon comes into play: our lightning-fast response to users' issues. We've implemented a support rotation that all our engineers take part in. When a customer reports an issue, we are able to take action immediately. There's no waiting, no lengthy backlog — just swift, decisive action to resolve the problem (and fix the bug if one exists). The Responsive Method is central to our engineering culture, shaping how we support both our customers and one another.

User interaction: Turning bugs into bonding

Our approach to handling bugs goes beyond mere problem-solving. We see it as an opportunity to forge stronger connections with our users. When someone reports a bug, it is not sent to a backlog and prioritized later to be handled by an engineer who has no context on the issue. Instead, we engage directly with the users who reported the issue. Doing so creates a personal connection that goes beyond the typical support interaction and helps provide useful context that the engineering team can use to improve the product. By doing this, we create more comprehensive solutions that address both the immediate issue and potential concerns in the future.

We also use these moments as opportunities to educate users. By taking the time to explain what caused the bug and how we will fix it, we help our users understand the product better. This transparency not only builds trust, but also empowers people to use our product more effectively.

Moreover, these support escalations become springboards for broader conversations. We gather feedback about the overall user experience, which provides invaluable insights for our product development. By being open about issues and involving users in the resolution process, we cultivate trust and loyalty that goes far beyond the immediate bug fix.

That low backlog of 17 bugs

Remember that low bug backlog we mentioned earlier? We do, in fact, maintain a backlog of only about 20 bugs at any given time. This isn't because we avoid encountering bugs — our focus on rapid release means we expect them. We might resolve over 100 issues in a typical month, but our approach is to address bugs so promptly that they don't have time to accumulate.

Our lean backlog reflects this responsive strategy. We don't push bugs into the next quarter or even the next sprint; we handle them quickly, keeping the backlog manageable and our customers satisfied. The agility comes from balancing rapid feature releases with efficient bug resolution.

During regular development cycles, our engineers focus on shipping new features. Then, during dedicated support rotations, they shift to addressing user-reported issues. Our dual-focus approach ensures we continuously improve our product while keeping it stable and reliable.

So even though we're not aiming to ship bug-free software (if we were, we'd be shipping too slowly), we've built a system where bugs are resolved almost as quickly as they're identified. It's this balance of speed, responsiveness, and continuous improvement that keeps our backlog lean and our users happy.

Why a lean backlog works

By swiftly addressing issues, we keep our customers engaged and connected to the product. This feedback loop continually refines our features based on real needs rather than assumptions. A lean bug backlog allows engineers to focus on rapid innovation without being overwhelmed by minor fixes. Bug reports become opportunities for improvement, creating a user-centered development process that keeps us in tune with evolving needs.

The takeaway

By prioritizing rapid delivery, being responsive to issues, and viewing bugs as chances to connect with users, we've created a system that fosters innovation while maintaining strong customer satisfaction. Rather than aiming for perfection, we focus on quick resolutions and ongoing improvement, allowing us to strengthen our relationship with users at every interaction.

Remember: Perfection is the enemy of progress. Don't be afraid to ship with a few rough edges — just make sure you're ready to smooth them out quickly when your customers notice them. Likewise, use every interaction as an opportunity to strengthen relationships with your users.

So, are you ready to love bugs as much as we do? Check out our open roles.