I’ve had a curious request from a client today. They were asking why their online sales and quote tracking system wasn’t calculating the percentages. Of course that’s a big deal because they need to know how well each sales person is doing over the course of the month.
Of course, I logged into our staging server to see what was happening.I looked at the calculations and they were correct. The correct values were being returned to the display, and the display was reading correctly. As the code base on the staging server and the production server are the same I couldn’t work out why it would be working on one and not the other.
Then I looked at the numbers that they had on their system. As it’s early in the month, they haven’t had a lot added into the system yet. The best that performer that they had was showing $322.00 worth of sales from their $799,242.00 budget. That gives their best sales person a current percentage of 0.0004%.
As there’s limited room on the screen, they’ve asked for the percentage column to display whole numbers, rounded down to the nearest whole number. Now, what’s the nearest whole number, rounded down, to 0.0004? It’s 0 of course.
Of course, they did realise that they were wrong, but they didn’t admit it.
This example goes to show you that just because someone reports a bug with a system, it doesn’t mean that it’s really there. A lot of the time it’s the users expectations that are not met, and not the system doing something wrong. This is the exact reason why there needs to be at least some formal documentation of what a system is meant to do, what it’s meant to display, and what happens if it doesn’t.
Let this be a lesson to all of us. Bugs do exist in the wild, and in vast quantities. But not everything is a bug, so make sure that you always track down what’s happening, and work from the facts, not just the reports.