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!

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? [...]

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....

Latest ideas

Our latest thinking about SF Commerce Cloud.

What eCommerce Platforms Are the Major Food & Drink Brands Using?
  • United Virtualities: We are UV
  • Commerce

What eCommerce Platforms Are the Major Food & Drink Brands Using?

What are the best food and drink brands powering their websites with? [...]

Beyond Prime: The Last Five Years of eCommerce and Retail
  • United Virtualities: We are UV
  • Commerce

Beyond Prime: The Last Five Years of eCommerce and Retail

What do the last 5 years of ecommerce reveal about its trajectory in retail? [...]

What eCommerce Platforms Do the Top Electronics Brands Use?
  • United Virtualities: We are UV
  • Commerce

What eCommerce Platforms Do the Top Electronics Brands Use?

Which ecommerce platforms are the very best electronics brands currently using? [...]

How can we achieve
awesomeness together?


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