Product Bugs are one of the most common and accepted parts of building tech products. Yet bugs are often overlooked or an afterthought, especially when it comes to thinking about how to improve productivity and, ultimately, get better outcomes for customers.
Bugs can even be a taboo topic. Some people want to believe that they won’t happen or don’t want to talk about them so that they don’t risk being seen as bad at their job.
From our partners:
No one intends to introduce bugs into products – I’ve never seen a roadmap naming the bugs a team wants to introduce – but product bugs must be planned for because they’re inevitable.
They’re so common that the US Department of Commerce concluded that “software bugs, or errors, are so prevalent and so detrimental that they cost the US economy an estimated $59 billion annually or about 0.6% of the gross domestic product.”
Macro statistics aside, you’ve been impacted by bugs personally if you’ve spent less than 15 minutes building or using tech.
This article is in the form of a guide, that aims to comprehensively cover everything you, your team and stakeholders need to think about when it comes to product bugs (software defects, errors, software bugs, or whatever you want to call them).
What Are Product Bugs?
Wikipedia defines software bugs as “an error, flaw or fault in a computer program or system that causes it to produce an incorrect or unexpected result, or to behave in unintended ways.”
For our purposes, we’re going to use the same definition for product bugs. Most tech products are heavily software or technology-based.
“Most bugs arise from mistakes and errors made in either a program’s design or its source code, or in components and operating systems used by such programs.” For products that have physical aspects or hardware, you can extend this to include errors or mistakes in the product’s physical design or production.
Why Do Product Bugs Occur?
A simple explanation for why product bugs occur comes from the definition above: mistakes and errors made usually by the people that built the product, but sometimes by the user.
The Institute of Electrical and Electronics Engineers, the IEEE, is the body responsible for standards in software. The IEEE has a Standard Classification for Software Anomalies which provides the following categories for causes of bugs:
The paper A Case Study: Software Defect Root Causes found that the majority of defects came from the Development process, with data and integrations coming in next.
Within the development process, there are a variety of ways bugs can occur, including:
- Changes to requirements, especially when changes are made later in the development cycle.
- Issues with the requirements themselves like omissions, conflicting requirements and logical mistakes.
- Failing to incorporate testing (manual and automated) into the development process.
- Testing, but testing too late in the development process.
- Avoidable mistakes from stressed and disenfranchised software engineers.
Bugs from integrations, anecdotally, primarily come from (mis)behaviour of another software system, undocumented functionality and unexpected changes in the other system.
Errors resulting from data processing problems are only going to rise due to the increase in the volume and uses of data.
Usability bugs are an interesting category in that often they are reported on or improved outside of thinking about bugs. For example, say a signup process isn’t performing as well as you think; it could because there are too many steps or screens. Usually, this isn’t reported as a bug but gets thought of as an improvement, unless the signup wasn’t built to the original signup specifications. We won’t resolve this issue here, instead, just make sure you are aware of it.
Usability issues also include accessibility issues (e.g. WCAG 2.0 compliance), problems to do with platforms or browsers (e.g. Apple v Android, Chrome v Safari).
Why Do Product Bugs Both Matter and Not Matter?
Product bugs matter because they are guaranteed to occur and they are guaranteed to have an impact on your product. Bugs could lose your customers, cause financial losses or, worse, injury or death (depending on your industry). Bugs can also lead to personal stress and angry stakeholders.
However, if bugs are accepted, respected and managed, then they don’t need to matter. Somewhat counterintuitively, by allowing for bugs to both happen, be allowed for in your software architecture and be part of your development lifecycle, then bugs matter less (or at least feel less painful).
If you’re running trying to rapidly understand, validate and grow a customer base, then your allowance for bugs becomes a necessity. Facebook is famous for and truly lived the phrase “move fast, break stuff”. You might not allow for as many bugs as Facebook did due to your customers, but equally, you might want or need to in order to get ahead in the market (Facebook has since rolled this back a bit).
You need to work out what allowance you will make for bugs depending on your circumstances. Zero bugs are usually not the right answer too.
You also need to work out what your priorities are to get this setting right, and to know whether bugs in plural or if a single bug matter.
Next Steps
In the second part of this guide, you’ll learn how to manage product bugs in-depth.
This article is republished from hackernoon.com
For enquiries, product placements, sponsorships, and collaborations, connect with us at [email protected]. We'd love to hear from you!
Our humans need coffee too! Your support is highly appreciated, thank you!
