Are Bugs Killing Your Momentum?

Software bugs are a common occurrence in the world of technology. If you ever wrote more than ten lines of code, chances are, you might have accidentally caused one.

Now, I'd like you to think about the last time you received a message from a customer or colleague freaking out about a bug. How did it end? Was the bug so urgent that you had to stop what you were doing?

In this article, we’ll try to challenge conventional thinking about bugs and explore how much each bug is costing you and your team.

About Me

Hey there 👋, my name is Krste, and I'm a full-stack developer who has been working in startups for over seven years. Recently, I co-founded Bugpilot, a bug-monitoring platform that alerts software teams about critical user-facing bugs.

I wrote this article with the goal of challenging the conventional thinking about bugs and the “we need to fix it ASAP!” mindset, questioning the need to explore the true cost of each issue.

100% Bug-Free Software. Myth or Reality?

The goal of achieving 100% bug-free software has always been a tricky one. The idea of creating a bug-less app may seem ideal, but is it actually possible?

The truth is that software bugs are inevitable due to complex business logic, human errors, and technology’s continuous updates. Even with careful testing and quality checks, it's difficult to eliminate them completely.

Thanks to new developer tools and improved processes, however, teams are now shipping new features at a lightning pace to be able to stay relevant and competitive.

And, with any change to the codebase, something is always possible to break. (Having to support many devices and multiple browsers doesn’t help at all.)

Of course, there are cases where bugs must be close to zero. Certain industries, like banking, medical, and aerospace, must ensure that mistakes are kept to a minimum, as they could potentially cost lives.

That explains why most software in these industries is written in technologies from decades ago and why people are now hesitant to touch it.

But in the end, we have to ask ourselves, "Is it all worth it?” For most of us building marketing tools and CRMs, I believe fixing bugs is often more expensive than leaving them around. I'll try to explain why.

Not All Bugs Are Made Equal

Imagine you're working on an e-commerce website, and a bug breaks the checkout process, making it impossible for customers to complete their purchases.

It is painfully obvious that this bug needs immediate attention since it directly impacts the core functionality and potentially results in lost sales and dissatisfied customers.

Similarly, we can't treat a bug in the Signup page that's preventing new users from joining our new ride-sharing app the same as an issue related to updating the profile photo.

These black-and-white examples show that not only do we need to detect, but we need a way to understand the impact of bugs. However, in reality, things are not black-and-white. Most situations fall within the gray area. The question then becomes: how do we know what to fix?

“wE hAvE tO fIx iT nOw oR tHe cUsToMeR wIlL LeAVe”

I've noticed that we tend to add an "extra" sense of urgency to bugs that our customers find.

You've probably been in a similar situation when one of your bigger customers is having a minor issue, and your whole team is getting flooded with messages as if the world was on fire 🔥

”Giovanni complained they can't right-align the text111 They are an important customer. We must fix the bug N-O-W!”

- your boss

Based on my experience, customer-facing roles such as customer success, support, and sales tend to prioritize issues depending on how the customer reacts and how it affects their reputation. This is why everything may seem like a big deal to them, which is understandable.

Nobody wants to make a bad impression or have a negative reputation, and that is exactly what bugs may cause.

The More Users Are Affected by a Bug, the More Important It (Probably) Is to Fix It

Sometimes, production issues are dealt with as they occur. Especially us developers jump right away on any bug or coding error that gets to their inbox.

You or your team might be using a tool such as Sentry or Bugsnag to monitor and get notified when errors happen. When any error is found, it is quickly assigned to a developer while everyone impatiently awaits an update in Slack.

Typically, these tools prioritize errors based on how frequently they occur and how many users are affected.

Human.prioritizeBugs()

However, the priority of most bugs in most teams is likely determined by either the product owner or the lead developer. These roles typically have an understanding of the business logic, underlying technology, current workload, and upcoming priorities and plan accordingly.

Their prioritization criteria might look something like this:

Is it critical or not? First question, but it is getting a bit tricky already. What's Critical? Critical doesn't have a clear definition. If a core function is unusable, then it's pretty obvious we must fix it. However, as you saw in the example above, what if an important customer is affected?

How many customers is it impacting? Just one? Everyone? Do we even know? When a significant number of users are impacted, you might want to address the issue, even if it is related to a minor functionality.

How much time does it take to fix it? Next, the owner of the “Bug Triage” process will ask how much time it takes to fix the issue. If it only takes a couple of hours, they will find ways to squeeze it into this week's work.

“To Fix (ASAP) Or Not To Fix, That Is the Question.”

Developers often face a dilemma when dealing with an "urgent" bug. They may either rush to finish their current task and fix the bug, possibly introducing new bugs in the process; they frequently ignore context-switching overhead, as they may abruptly switch their attention to the bug, abandoning their current task altogether.

There are three significant problems with these scenarios:

1. The team prioritizes incorrectly, resulting in possibly wasting time and fixing less relevant bugs.

   
   

2. Adding unnecessary urgency to non-critical bugs causes the team to switch focus unnecessarily.

   
   

3. Before addressing a bug, it's important to consider its cost. So, how much is a bug actually costing the team? Is fixing it a reasonable cost?

How Expensive Is It to Fix a Bug?

Have you ever heard of the phrase "There's no such thing as a free lunch?"

When we talk about cost, the first thing we think about as devs is infrastructure cost, the cost of a server, a Lambda Function, a MongoDB Cluster, and so on. However, when it comes to bugs, I'm talking about a human-related cost: attention.

Context Switching

If you studied computer engineering or you’ve ever read about how OS work, you’ve probably heard of context switching.

In computing, a context switch is the process of storing the state of a process or thread, so that it can be restored and resume execution at a later point, and then restoring a different, previously saved, state.

(from [Wikipedia](https://Context switch https://en.wikipedia.org › wiki › Context_switch))

One case of OS-context switching might be Multitasking: Context switching is characteristic of multitasking that allows the process to be switched from the CPU so that another process can be run.

Where have I heard these words before 🤔? - Ah, yes:

“I Am a Master at Multitasking.”

Multitasking can take place when someone tries to perform two tasks simultaneously, switch from one task to another, or perform two or more tasks in rapid succession.

Doing your laundry while talking with a friend will probably work out all right. The tricky part comes when we are doing mentally complex tasks, like writing code.

Psychologists have conducted multiple experiments on task-switching to determine its costs. They measured the time it takes for people to complete tasks and the time cost of switching between them. The results were the following:

“Although switch costs may be relatively small, sometimes just a few tenths of a second per switch, they can add up to large amounts when people switch repeatedly back and forth between tasks. … shifting between tasks can cost as much as 40 percent of someone's productive time.”

“Do You Have a Minute?”

Picture this: you're locked in, fully immersed, and nothing can stop you from finishing this new, shiny feature. The outside world doesn't even exist - it's just you and your code. But then, you hear a ring out of nowhere... a new notification on your phone.

It's your friend asking you out for drinks this weekend. And just like that, poof, the next 20 minutes of your life are gone.

Or maybe you just received a Slack message from your colleague asking if you have a minute to help with a specific issue.

Is the second situation more acceptable than the first?

Well, in the end, it doesn’t matter. Based on an analysis of 10,000 programming sessions recorded from 86 programmers using Eclipse and Visual Studio and a survey of 414 programmers (Parnin:10) found:

• A programmer takes 10-15 minutes to write more code after resuming work from an interruption.

• When interrupted during an edit of a method, only 10% of times did a programmer resume work in less than a minute.

• A programmer is likely to get just one uninterrupted 2-hour session in a day.

Developers tend to avoid (and hate) context-switching when it’s about useless meetings. Still, I believe we might be somehow blind when we context-switch between “developer tasks” and completely ignore its negative effect.

Final Thoughts

In the real world, we are always dealing with limited resources, whether it’s money, time, or attention.

Fixing Bugs Has a Price.

“No” is no to one thing. “Yes” is no to a lot of things. – Jason Fried

Saying “yes” to fixing a bug means saying “no” to a feature. Multitasking may seem efficient on the surface, but switching between tasks takes more time and introduces more bugs in the end.

Understanding the hidden costs of context switching helps you make better choices on which bugs are worth dropping everything for and which ones aren’t (most aren’t).

Should We Stop Caring About Bugs?

Well, no. However, we should at least be aware of the cost of fixing bugs and ask ourselves, "Is it worth fixing it?” It can be challenging to sit calmly and accept bugs. We all have an inner desire to produce high-quality work and build something we can be proud of.

Unfortunately, those pesky bugs often get in the way.

As Tom De Marco writes in his book "Peopleware", this might explain why it's tough to stop caring about quality:

We all tend to tie our self-esteem strongly to the quality of the product we produce—not the quantity of product, but the quality. (For some reason, there is little satisfaction in turning out huge amounts of mediocre stuff, although that may be just what’s required for a given situation.)

– Peopleware

Should We Put More Effort Into Bug Prevention?

As I mentioned earlier, you don't have a choice in many industries. There, you must take all necessary steps to prevent mistakes from occurring and correct them as quickly as possible.

But, for most apps, is the extra effort worth it?

P.S. At the end of the day, even if we had a magic wand that fixes all bugs, our users would still find a way to misuse our app 😅