What is a bug?
Whenever we encounter a bug, we typically drop everything and fix it since this is affecting users. However, as a founder-coder, I've often fallen into the pitfall of treating everything as a bug. A UX issue? It's a bug. A UI issue? It's a bug. A minor inconvenience? A bug. New feature? Also a bug. Unfortunately, this will eventually lead to a lack of prioritization. You may end up finding yourself pushing a lot of updates but nothing that takes your software to the next level. So, we decided to properly answer the question, "What is a bug?"
Here is what we consider a bug:
- Something that was previously working, but it's not working anymore.
- Something that’s working incorrectly. Emphasis on incorrect.
Here is what we consider an enhancement:
- UX Change
- UI changes
- Changes to an existing feature
- New features
- Paper cuts
For example, "adding right click to open in a new tab" is not a bug, but "right click to open in a new tab is not working anymore" is a bug.
We also further classify bugs into two buckets:
- First-party bug - the bug is from our system, and we have complete control over it
- Third-party bug - this bug stems from integration with a third-party system. It could be that a third-party system recently changed their behavior or started enforcing new rules.
For first-party bugs, we drop everything and fix it. The turnaround time is usually 48 hours at most, but most of the time, we fix it right away and deploy it to production. Maybe 30 minutes?
Third-party bugs are tricky, and depending on how much communication and document pouring we must do, it might take us a week or more. Unfortunately, there is not much we can do here, but we will strive to resolve it as quickly as possible. Our turnaround time is usually 48 hours. Sometimes, it takes us much longer, especially when it involves QuickBooks Online.
Only once did we remove the integration altogether. We removed our native UPS and FedEx integration and replaced it with Shippo. UPS and FedEx changed their API format from SOAP to Rest, and we decided to just integrate with Shippo, which offers many carrier integrations. It was regretful, and I hated doing it, but it had to be done if we wanted to push YoPrint forward.
We don't segregate bug severity since we get only a few bugs a week at most. If you need to classify bug severity in your system, I think you have a different problem, and maybe you should revisit how you develop and ship software.
By defining what's a bug and what's not, we were able to start shipping more meaningful features. We usually use in-between cycles to ship out a few of the enhancements requested, maintaining a balance between bugs, enhancements, and new features. As to how to prioritize enhancements and new features, we go with our gut feeling. The key is to make sure the scale doesn't tip over one side too much.