What Is A Bug

09:43 What is a bug?

“The term originally comes from the really really old computer days when somebody found a moth in physical hardware”

It’s a defect in software when compared to the specifications for that software. It’s an error or flaw in an app that causes an incorrect or unexpected results. This definition is good enough for most purposes.

If you are doing things like working on fixed bid projects, the definition needs to expand to compare the output to what the product owner or client asked for, rather than merely saying it was “unexpected” or “flawed”. It would be more honest to stop referring to bugs as “bugs” and call them defects, instead, but the industry doesn’t typically do that.

“As an industry if we want to grow up we probably need to stop calling these things bugs and instead start referring to them as defects.”

The definition of a “bug” is context-dependent. A slight issue with graphics might just be a cosmetic issue if you have a simple ecommerce site, whereas it may well count as a bug for the purposes of a client who paid for a heavily graphical, artsy website.

Handle bugs as soon as possible, based upon the severity and impact of the issue, weighed against the difficulty of fixing it. This doesn’t mean death-march speed. If it wasn’t enough of an emergency to get caught in testing, then it isn’t enough of an emergency to work 80 hour weeks fixing it.

21:26 Schedule adjustment

“I have been pulled off of a project for a sprint to go work on something else because we had a developer leave.”

This is not a bug. Instead it is where the priority or timeline of a task was abruptly changed. This can happen due to a sudden change in priority, changes pushed by sales, or by regulatory changes. It can also happen when other people fail to plan ahead or manage expectations.

This can also be context-dependent. Sometimes the change in schedule is needed to keep the company afloat, but it shouldn’t happen often unless it is an early stage startup.

“These are not bugs, but you do still have to triage it.”

Ask management to lay out priorities to make sure they know how busy you already are. Explain to them the cost of switching tasks and make sure you have time to get to a good stopping point. Make sure you keep enough information to be able to get going again quickly when you start back.

30:20 Cosmetic Issues

“I’m not going to listen to QA when they tell me it should be this way because ‘this is the way I wrote my test case'”

These are graphics or presentation issues that don’t cause damage. These can be things like CSS issues, graphics that the clients don’t like. This sort of thing can often cause users to panic, but it’s not a huge deal unless they can’t actually get things done.

“A lot of times it’s stuff that’s not a big deal unless people can’t get things done.”

These can also be context-dependent. If the cosmetic issues are bad enough that they are costing money, or damaging to the brand, they can be serious.

First look for a workaround. This gets the emotional pressure off of the situation. Because non-developers frequently can’t tell the difference between data not being in a control and data not existing, this is an important first step. If your organization is big enough to have a graphics/css group, this might be a good time to hand off to them. You can also pass these off to junior developers or interns who are just starting out.

39:27 Feature Requests

“This can hit your financials if you start treating feature requests like bugs.”

These are things that people want added to existing code. These can anything from additional fields on a screen, all the way up to new features in the software.

“You can really make a difference in somebody’s life with a line of code.”

There are times when you will get requests for additional features that must be completed quickly, either to secure a new client, to handle a regulatory requirement, or as a prototype for a sales demo. Nevertheless, this shouldn’t happen unless you are in a very early stage startup.

“You don’t want to be reacting and creating new features”

Feature requests need to be run by management or project management. You should not start new feature requests until authorized, as feature requests can often come with a price. Make sure that you get adequate specifications on a new feature before beginning.

46:00 Security Issues

These are issues that allow people to access or change data they shouldn’t have. These can be anything from forgetting to secure part of a website, to things like SQL injection, Cross Site Request Forgery, or Cross Site Scripting attacks that require you to change code. Many of these can be issues that have nothing to do with your code and everything to do with risks taken in from outside your application.

“It’s a toss up whether these are properly called defects.”

These security issues usually require a prompt response, both due to regulatory requirements and due to the risk of loss.

You’ll probably have to stop what you are doing and fix it, but you need to make sure you can quickly get back to what you were doing after it is over. There should be some detail on the vulnerability, including steps to reproduce and how to test it. Do not start without those. This is an excellent time to be thinking about where else the same approach has been used in your app, because it’s worth taking the time to get ahead of these things.