Blurred background image

How we define a bug

How we define a bug.

In software-development-land, one of the most basic concepts is a “bug”: that’s a problem in your software. In fact, in the down and dirty real world of software development, it’s one of the most basic concepts: a lot of software management and organization revolves around “bug tracking software” and other such systems.

And the definition of a bug, as something not working, is fairly straightforward. As an example, when you Google it, the first definition that appears is from Technopedia, which defines it as:

A software bug is a problem causing a program to crash or produce invalid output. The problem is caused by insufficient or erroneous logic. A bug can be an error, mistake, defect or fault, which may cause failure or deviation from expected results.

Most bugs are due to human errors in source code or its design. A program is said to be buggy when it contains a large number of bugs, which affect program functionality and cause incorrect results.

In other words, it’s when the program doesn’t work. 

But here at UV, we tend to approach things from a different angle than those who just follow the guidelines without thinking about them. We look at guidelines, think about what they mean, and sometimes follow them but sometimes tweak them. (As we described in depth in our recent process vs flexibility article.)

Before we give you our working definition of a bug, let me translate what the official definition, as articulated above for example, translates into. The official definition, restated, is effectively this:

When software doesn’t work according to the way it was programmed to work.

Pretty clear and straightforward. Same thing, right? Now compare this to the very slightly different definition that United Virtualities uses:

When something doesn’t work according to our client’s expectations of how it should work.

That difference may sound like word-play, but to us, it is actually a very different situation.

Let me explain the difference between the two. Outside of UV, a bug is usually considered when something doesn’t work according to the expectations of the software developer who wrote it. But here at UV, we consider something a bug when it doesn’t work according to the expectations of a client. The key difference is the noun, the subject of the sentence: whose expectation is it. A bug for a developer is when it doesn’t do what he meant to program it to do; a bug for a client is when it doesn’t do what in his mind he imagined it should do.

In practice, this results in a substantially different way to think about, treat, deal with, and solve bugs. As an example:

Imagine you’re building an ecommerce site, and you hire a not-as-awesome-as-UV team to build it. It’s all delivered, and in final testing to go live! And let’s say, you add something to the cart and then it’s just not added to the cart. You then tell the software developer, “Hey! While testing the product, I added an item to the cart but it just wasn’t added — I found a bug.

Here is how most software developers, outside of UV, that we know would respond: “Oh, that’s not a bug. You see, that particular product is currently sold out. So it can’t be added to the cart. And in our specifications, and in our standups, we never defined what should happen in this particular case other than no error being thrown. So the software is working perfectly, the way it was programmed to work. This is a new feature request.

But at UV, here’s how we would respond: “Oh! From the eyes of the average site visitor, clearly that’s a problem and it should give you a message to note that it couldn’t be added to the cart since it is sold out. I’ll create a ticket now to solve this.” (But of course this is the sort of situation we try our best to account for beforehand to prevent but, alas, no battle plan survives contact with the enemy, as the old saying goes.)

Which way would you rather have your team respond to you, when problems like these happen? Yes, we think so, too.

Related Ideas

If you got value from this article, you may enjoy these other articles, as well. We’re always adding value!

Are You Asking Stupid Questions?
  • United Virtualities: We are UV
  • Firsthand Accounts
  • Glimpses of UV
  • Software

Are You Asking Stupid Questions?

Does your workplace cultivate a space for questioning? It will save you hours of wasted time....
Yes, YAGNI, You're Young: UV's Take On The YAGNI Debate
  • United Virtualities: We are UV
  • Software

Yes, YAGNI, You're Young: UV's Take On The YAGNI Debate

UV weighs-in on one of the ongoing tech debates. It's time to talk about YAGNI. [...]

...
Fit and Healthy with Agile Methodologies
  • United Virtualities: We are UV
  • Development
  • Software

Fit and Healthy with Agile Methodologies

What were the origins of the hegemonic software development methodology of Agile? [...]

Latest ideas

Our latest thinking about SF Commerce Cloud.

Digital makeover with Salesforce Commerce Cloud
  • United Virtualities: We are UV
  • Commerce
  • Salesforce Commerce Cloud

Digital makeover with Salesforce Commerce Cloud

Following the digital transformation of e.l.f. via Salesforce Commerce Cloud, they’ve managed to thrive during the lockdown. [...]

Four Festive Forecasts for the Finale of 2020
  • United Virtualities: We are UV
  • Commerce
  • Salesforce Commerce Cloud

Four Festive Forecasts for the Finale of 2020

Looking into a crystal ball, what can we expect from ecommerce retailers and brands during the holiday season? ...
What is the Cost of Adobe Experience Manager?
  • United Virtualities: We are UV
  • Adobe Experience Manager

What is the Cost of Adobe Experience Manager?

What is the cost of running Adobe Experience Manager? [...]

How can we achieve
awesomeness together?


UV has acquired SFCC & AEM specialist dev shop, Sawyer EffectLearn all about it!