This is part two of the blog on Bugs and Features.
To reiterate, the term “bug” is used to describe problems with, or defects in, a product or code base. A feature on the other hand is often a discrete piece of functionality that is requested and desired by stakeholders, or a change request that must be fulfilled. At times bugs can be viewed as features and vice versa.
In this blog we will be focusing on the etiquette of bug fixes, when we fix them and how you approach bugs of varying difficulty. We will also be working through when you decide to develop a new feature in response to a bug.
The Etiquette of bug fixes
First and foremost, don’t write bugs
One of the most basic ways to go about fixing bugs is to not write them in the first place. This may sound redundant, but often as a software dev, you may find yourself writing code or using a convention that you subconsciously are aware may later result in bugs. The last thing you want to do is write code that adds code debt to your product.
Weigh up the fixing cost against the benefit of fixing the bug
As far as possible, you never want to have code that has an excessive number of bugs. As such it is good to adopt a zero defects methodology, much like Microsoft did.
Microsoft universally adopted something called a “zero defects methodology”. Many of the programmers in the company giggled, since it sounded like management thought they could reduce the bug count by executive fiat. Actually, “zero defects” meant that at any given time, the highest priority is to eliminate bugs before writing any new code.
Fixing bugs as your first priority made sense in the year 2000, and it still makes sense today. However, prioritizing bug fixes can come at the expense of developing new product features. From this, the client needs to decide which one is a greater value add?
Fixing bugs will always take time, especially if it is a code base that you are unfamiliar with. There is no perfect way or balance between the two, only an awkward middle point. As a developer, you need to determine what type of code you would strive to write.
Make use of an issue tracker
It is always a good idea to keep track of bugs as they surface. This allows the other devs to readily see what needs to be worked on with the product, as well as the fact that you cannot fix something you don’t know is broken.
As a result, the issue tracker is an essential piece of the debugging process. It can be used to store a list of current bugs, prioritize them, record information, and communicate status back to support staff or users.
Fixing bugs can stagnate a product
Starting a new feature is more enjoyable for developers than hunting down bugs. Few developers would prefer to spend a week tracking down and fixing a hard-to-reproduce bug when they could be doing a new and interesting feature. A product manager needs to be particularly firm in making sure bugs consistently get priority.
This is why it is vitally important to accurately gather all the information when you are logging the bug. This includes:
- Steps to reproduce the bug
- Be as detailed as possible in this stage
- Expected behavior
- Actual behavior
- System configuration
- Any additional information, such as crash reports, debug logs and other system information, such as available storage or RAM.
Too many bugs, identify tool?
Sometimes there exists the case where the code that has been written is riddled with bugs. This then brings forth the challenge where we cannot decide where to start fixing the bugs. Here are two factors to take into account; the importance of the bug, and the urgency behind the broken code.
- Importance refers to how much the bug impacts vital functionality or secondary functions. It must also acknowledge the availability of workarounds and how many users are affected overall.
- Urgency refers to how long a bug can wait on the back burner. Is it preventing users from accessing necessary functionality? Is there a deadline where they need access again??
New features in software development
Bugs too hard to fix?
But what if the bug in question is hard to fix and doesn’t affect many people? You might argue that it is better to add a new feature that will help many users, rather than spend the same time fixing a bug affecting only a few users.
The problem with this logic is that when it is applied over and over again, you’ll end up with a product that is feature rich but riddled with defects. Many users will have a terrible experience.
When trying to decide on which bugs to fix or features to add, try using the MoSCoW method: things your product Must have, Should have, Could have, or Won’t ever have.
In general, features attract new users and bugs repel existing users. If you don’t fix bugs first, your buggy product will have terribly high churn. Word-of-mouth, if any, will be the negative kind where people warn their friends not to use your product.
Your product is much better with just a few features that are well-designed, well-tested, and hardened through rigorously prioritizing bug fixes.
The slow pace of development can be frustrating when you have customers requesting feature after feature. This is the brutal reality of software development: coding a new feature seems to be quick, but finding and fixing all bugs in the feature takes way longer than novice product managers expect.
