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 , a bug-monitoring platform that alerts software teams about critical user-facing bugs. Bugpilot 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, ” For most of us building marketing tools and CRMs, I believe I'll try to explain why. "Is it all worth it? fixing bugs is often more expensive than leaving them around. 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 However, in reality, things are not black-and-white. Most situations fall within the gray area. we need a way to understand the impact of bugs. 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 customers is having a minor issue, and your whole team is getting flooded with messages as if the world was on fire 🔥 bigger ”Giovanni complained they can't right-align the text 1 They are an important customer. We must fix the bug N-O-W!” 11 - 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 or to monitor and get notified when errors happen. Sentry Bugsnag 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 might look something like this: prioritization criteria First question, but it is getting a bit tricky already. What's Critical doesn't have a clear definition. If a core function is unusable, then it's pretty obvious we must fix it. Is it critical or not? Critical? However, as you saw in the example above, what if an important customer is affected? 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 many customers is it impacting? Next, the owner of the 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. How much time does it take to fix it? “Bug Triage” “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 , as they may abruptly switch their attention to the bug, abandoning their current task altogether. context-switching overhead There are three significant problems with these scenarios: The team prioritizes incorrectly, resulting in possibly wasting time and fixing less relevant bugs. Adding unnecessary urgency to non-critical bugs causes the team to switch focus unnecessarily. Before addressing a bug, it's important to consider its . So, how much is a bug actually costing the team? Is fixing it a reasonable cost? 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 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. context switch (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. 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: Psychologists have conducted multiple experiments on task-switching “ 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, , the next 20 minutes of your life are gone. poof 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, recorded from 86 programmers using Eclipse and Visual Studio and a survey of 414 programmers ( ) found: it doesn’t matter. Based on an analysis of 10,000 programming sessions Parnin:10 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 ( ) 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. and hate 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 Multitasking may seem efficient on the surface, but switching between tasks takes more time and introduces more bugs in the end. Saying “yes” to fixing a bug means saying “no” to a feature. helps you make better choices on which bugs are worth dropping everything for and which ones aren’t (most aren’t). Understanding the hidden costs of context switching Should We Stop Caring About Bugs? Well, no. 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. However, we should at least be aware of the cost of fixing bugs and ask ourselves, "Is it worth fixing it?” Unfortunately, those pesky bugs often get in the way. As Tom De Marco writes in his book , this might explain why it's tough to stop caring about quality: "Peopleware" 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 😅

Are Bugs Killing Your Momentum?

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Is Software Testing Really Worth It?

10 Must-Follow Tips for B2B SaaS Companies

5 Ways Content Marketing Benefits SaaS Companies

Alternative Pricing: Letting Go of Bad-Fit Customers is For the Best

Attention B2B SaaS Founders: Start Tracking These Metrics From Day One

B2B Trends Every Salesperson Should Know About

Is Software Testing Really Worth It?

10 Must-Follow Tips for B2B SaaS Companies

5 Ways Content Marketing Benefits SaaS Companies

Alternative Pricing: Letting Go of Bad-Fit Customers is For the Best

Attention B2B SaaS Founders: Start Tracking These Metrics From Day One

B2B Trends Every Salesperson Should Know About

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps