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.
