Bystander Effect

Have you ever seen a bug in an application but no one on the team seems to log the bug. You too fall in a dilemma - to log or not to log the bug.

When I asked around, about why someone would ignore to log a bug that is starring in their face,

The answers I got in the order of frequency -

1. I don't think this is our team's issue.
2. I don't think it is an important issue.
3. I think it is a one time issue.
4. Logging this bug will delay the sign off on this build.
5. I am sure some one else logged it.
6. This is a known issue we don't need to log it.
7. This is how it seems to function all the time.
8. I don't think this is a bug.
9. I don't think they can fix this issue.
10. Why should I log it when everyone else ignored it?

The reason for this kind of attitude seems to be same as the Bystander effect where individuals do not offer any means of help to a victim when other people are present. 

Now, what could be a reason for this kind of reaction?

1. Diffusion of responsibility!!
2. Looking to others for guidance in Ambiguous situations.

How could this issue be rectified?

I do not know how this issue is addressed in most IT teams, but this is how I tried to solve the issue. -

1. Don't ignore it, just because you don't understand it at the moment.
2. Don't be afraid to log the Bug. It does not matter who is responsible for testing it. It is our collective responsibility to make sure the product is bug free.
3. Bring it to your team members attention to verify your findings.
4. Bring it to your lead's attention if you are not able to get help.
5. Don't be afraid to speak out again and again. It is okay to ask questions all the time. You will only get answers and more information and exposure.
6. If you are afraid of embarrassment, assign it to me instead of the Dev lead. I will re-verify and go from there.
7. Look for the people who could know the answers to the issue, contact them appropriately.
8. Don't avoid exploring the product with various variables out of fear of being called unnecessary.
9. It is okay to make mistakes. Mistaking does not make you any less intelligent.
10. Pick a designated lead who would re-verify the issue before assigning it back to the Dev lead. If you are the team lead, assign it to yourself and ask questions before assigning it to the Dev lead.

Vanilla Ice Cream caused General motors to not start

Vanilla Ice Cream that puzzled General motors’!!!!

An Interesting Story

Never underestimate your Clients' Complaint, no matter how funny it might seem!

This is a real story that happened between the customer of General Motors and its Customer-Care Executive. Pls read on.....

A complaint was received by the Pontiac Division of General Motors:

'This is the second time I have written to you, and I don't blame you for not answering me, because I sounded crazy, but it is a fact that we have a tradition in our family of Ice-Cream for dessert after dinner each night, but the kind of ice cream varies so, every night, after we've eaten, the whole family votes on which kind of ice cream we should have and I drive down to the store to get it. It's also a fact that I recently purchased a new Pontiac and since then my trips to the store have created a problem.....

You see, every time I buy a vanilla ice-cream, when I start back from the store my car won't start. If I get any other kind of ice cream, the car starts just fine. I want you to know I'm serious about this question, no matter how silly it sounds "What is there about a Pontiac that makes it not start when I get vanilla ice cream, and easy to start whenever I get any other kind?" The Pontiac President was understandably skeptical about the letter, but sent an Engineer to check it out anyway.

The latter was surprised to be greeted by a successful, obviously well educated man in a fine neighborhood. He had arranged to meet the man just after dinner time, so the two hopped into the car and drove to the ice cream store. It was vanilla ice cream that night and, sure enough, after they came back to the car, it wouldn't start.

The Engineer returned for three more nights. The first night, they got

chocolate. The car started. The second night, he got strawberry. The car started. The third night he ordered vanilla. The car failed to start.

Now the engineer, being a logical man, refused to believe that this man's car was allergic to vanilla ice cream. He arranged, therefore, to continue his visits for as long as it took to solve the problem. And toward this end he began to take notes: He jotted down all sorts of data: time of day, type of gas uses, time to drive back and forth etc.

In a short time, he had a clue: the man took less time to buy vanilla than any other flavor. Why? The answer was in the layout of the store. Vanilla, being the most popular flavor, was in a separate case at the front of the store for quick pickup. All the other flavors were kept in the back of the store at a different counter where it took considerably longer to check out the flavor.

Now, the question for the Engineer was why the car wouldn't start when it took less time. E..ureka - Time was now the problem - not the vanilla ice cream!!!!  The engineer quickly came up with the answer: "vapor lock".

It was happening every night; but the extra time taken to get the other flavors allowed the engine to cool down sufficiently to start. When the man got vanilla, the engine was still too hot for the vapor lock to dissipate.

Even crazy looking problems are sometimes real and all problems seem to be simple only when we find the solution, with cool thinking.

My sister shared this story on WhatsApp. I do not know the source of this story.

But it does remind me of the time, when one of my applications started throwing error even when using a valid account number. It turns out the Account type was not the issues, when the account was created was not the problem. The number of digits in the account number was the problem!!

Bugs you see Bugs you don't

The sight of fruit flies swarming over fruit is gross. the first thought that comes to the mind is get rid of the flies.

The sight of a burger with fries is mouth watering. The first though that comes to the mind is eat it. It looks good, it looks good even after a few months. No mold, no flies, and it is finger yummy.

Let's take a closer look. The fruit is organic and yummy. Of course the bugs want a piece of

something good. The organic fruit is not long lasting, it decays pretty fast.

The burger and its ingredients are over processed (probably with chemicals) to last a very long time and to withstand transportation and taste the same no matter where in the country (sorry world) it is made.

We view bugs as a bad thing. Too many bugs as a very bad thing. We are brainwashed to viewing bugs as a bad thing. If the product worked right, it should not have any bugs. But all bugs are not equal. Most are easy to fix (like a CSS alignment are harmless), especially the ones that are easy to spot with eyes wide shut.

But what about the bugs that are introduced unwittingly as features? There are features that cause serious issues relating to user experience (financial/ physical health) and security. They are not obvious on the first sight, they in fact look very good on paper. They do not cause damage on first use, they damage the insides slowly while a whole team stands by defending it.

Back Story - On one of the products  I worked on - I once came across a bug, where when I entered the wrong password for the username, the login page threw an error message but when I opened a new tab of the same homepage, it logged me in too. When I logged the bug, I was told, that - it is the result of the new re-arch (which authenticated the user based on the email address alone, something else, blah blah ) and hence the ticket was closed with the justification of  - "By Design"as well as the usual - "our users won't open a new tab".

• It takes a special team to identify the real issue and take responsibility.
• It takes a special kind of developer to offer an effective solution.
• It takes a special kind of problem solving to not have a knee jerk reaction to fix something in a way that makes it fundamentally wrong.
• But mostly importantly, it takes common sense to find issue like this. (Trust me, the web is full of such bugs)

Tell me about crazy bugs you have encountered that were by design (cough bad design)