"Clearly, it’s not a bug, it’s a feature," one of my favorite lines in software development. I need to say this once in a while to poke fun at bugs I come across. As the lines blur even further with between development and operations teams, traditional infrastructure teams can start to look like software engineering teams and vice versa.
Core to innovation work is trying novel approaches that have not been done before. As humans, we are fallible thus as we create systems our systems are subject to our fallibility. Though a traditional infrastructure team’s relationship to bugs might be more for work requests versus a traditional development team where bugs are errors that should get corrected.
Resources are finite and at some point, we have to ship our software for our internal or external customers to use. In the software industry, any problem can be solved with enough resources and time, though we are always constrained on those two items. Bugs are inevitable in the work we create.
What is a Bug?
The literal definition of a software bug is an error or flaw in a computer program that causes it to behave in unintended ways. From a developer perspective, another joke might be “the bug is between the keyboard and the chair” meaning the user. Bugs can go by many names; issues or defects are common names for bugs.
Bugs can appear at any time. A lot of work that we do during testing and validation phases of the SDLC is to shake out and validate the presence of issues. What we are testing for is if the feature matches the expectation. The expectation should relate back to a requirement, an SLA, or a reasonable expectation of functionality. Bugs are always to be expected but when you start to get too many of them or they start to come in at an increased velocity, quality comes into question.
Common Measure of Software Quality
Looking at the vitality of a software project either commercial or Open Source, the first measure of quality is the number of defects. For an average person looking in without context, the higher the number of defects the quality and vitality of a project might come into question. Though the ability to close those defects is equally or more important e.g defect-to-close ratio.
In Open Source projects, most projects allow for almost anyone to create an issue. For example at the time of writing this blog post, the Spinnaker Project has over 350 open issues throughout the platform. To make sure that filing in issue is not someone looking for help, most Open Source projects and commercial vendors will ask qualifying questions and help to reproduce the issue. Though depending on impact, not all bugs are created equally.
Not All Bugs are Created Equally
At my second internship at a big software company over a decade ago I was shocked to find out that we do not fix 100% of bugs before shipping the software. We were going from version 5.x to version 6.x of the application server we were building and we already knew what was going in the first service pack and we did not even ship the major release yet. My rose-colored glasses were cracked.
This concept had to do with bug prioritization; all bugs are not created equally. What we were weighing if any of the bugs discovered should be build or release stopping; a critical must fix or can the bug be deferred/fixed with a different approach or education. Prioritization is crucial that you will almost certainly not have the bandwidth to validate and fix every bug.
Prioritization factors in when and where did the bug comes from. Is the bug on a larger module that impacts more of the software or is the bug a specific edge case that has not been captured. The severity also weighs into prioritization; is the bug severe enough to cause a work stoppage for your customers or can a workaround be easily provided. Since resources are finite, ranking issues become part of the day-to-day job for development teams. Luckily there is plenty of help of keeping track of bugs with proactive quality and bug tracking tools.
Bug Tracking Tools
One of the first tasks you will do on a development team is to take a look at the bug backlog.
Most likely you will be cracking open Jira or GitHub Issues to take a full look at the rank/urgency and the type of bugs you will be dealing with. Usually, your first contributions to the team getting into the fold are helping bring down the bug backlog.
Other honorable mentions for bug tracking tools are Bugzilla and Rational ClearQuest. If not building a feature, modern development teams will include the ticket/issue numbers as part of their builds and deployments for the ability to trace back. Depending on the mechanisms the team has your team might be using a ticketing/bug tracking system fo enhancements or work requests. ServiceNow is a good example of a platform used to orchestrate work requests. As we start to embrace more automated testing and post-deployment continuous validation, bugs will be part of the decision factors in your Continuous Delivery pipelines.
Bugs and your Continuous Delivery Pipelines
Modern DevOps tooling needs to integrate with bug tracking tools. With the velocity and agility in which we work, human-centric tasks such as writing up a lengthy bug report can seem tedious especially with the wide automated coverage we come to expect.
Running your Continuous Delivery pipeline might be the first time that the automated coverage is being orchestrated and the findings will need to be reported or used as quality gates. As bugs, regressions, issues, etc start to be captured in more automatic formats, firms like Bugsnag are gaining traction, and the ability to automatically log tickets starts to be the norm.