It’s not working

There are a few things in life that I don’t like. They are so few that I couldn’t even remember them all now. But what I don’t like the most is when a developer tells me that the _____ (blank) doesn’t work. I will tell you exactly why I go bananas when this is th only thing I hear. When the code throws a white flag due to an unchecked runtime exception, blank doesn’t work. But blank doesn’t work either when  the computer does not start, or when power runs out. So, how the hell am I supposed to know what the problem is and how to fix it?

You know, I’ve had my share of “doesn’t works” from my users. Onetime, I was on the phone for over half an hour with an end user when the website was ” not working”. At the end, it turned out that he was looking at the website using Outlook (where all JavaScript was disabled from the view panel). Even with him telling me that he was 100% sure he was on Internet Explorer and still wasn’t able to see the menu options I was asking him about, I am still OK with that. What I am not OK with is when a developer wastes 1 minute of my time becaus she reported “it doesn’t work”.

Even for a QA, I wouldn’t mind hearing that from. As a matter of fact, I consistently tell my developers who complain about the QA not providing enough information to reproduce (and we all know how QAs and developers get along with each other), I tell them that when a QA doesn’t deliver enough information about a problem then it is the developer’s fault for not providing enough information about what is expected or providing enough logging for the QA to use and report more. I can live with a QA that dusts off all responsibility, and blow it my way through a “it doesn’t work” remark, but I sure cannot stand it when a developer says that to me.

There is a reason a language has millions of expressions and many overloaded words to describe events and happenings slightly differently from one another. Imagine all poems had the same word or sentence repeated over and over and over again. Oh wait, that’s most of our today’s music. But you get the point. “It doesn’t work”, is not a good description of what a problem is. This wastes time communicating back and forth to get more complete information. It also paves the way to sarcasm, which leads to disrespect and inflating politics. It further leads to, which is where those situations usually end up, being dangled in the middle of nowhere like a horribly coded unreachable else statement. That is how bad code builds on top of other bad code and problems.

Remember when I said there is nothing I don’t like more than a developer saying “it doesn’t work”? Well, I also want to tell you that I hate something else. And here I am using “hate” to describe (differently) how this is worse in my opinion than the thing that I don’t like the most which I talked about above. So, what’s worst than “it doesn’t work”? “it still doesn’t work”! Those statements sound the same right? Wrong! They sound as similar as Obama’s and Cheney’s hunting skills. I think Cheney is better at shooting his friends than Obama. When a developer comes back and says “it still doesn’t work”, from my experience, that means the new code with the fix produced the exact same error when the same scenario was run with all other influencing factors held constant and invariable. But, more often than not, it “also” means that I ran the new code with a different scenario and got the same error. Even worse, I ran the new code with a new scenario and got a new error. Yet, all testing scenarios described above were abstracted and encapsulated behind the same expression “it still doesn’t work”. When an end user or a QA says that, to me it means that the application is still not working. No matter the input or the scenario run. The end user or QA does not know all execution paths of the code from a low level perspective. They know a use case only. It is not their job to map a use case to an execution path in the code. That is the developer’s job. If you want more information from your QA, empower them with logging tools and knowledge. But be careful not to mix their responsibility as a QA with a developer’s responsibility to “debug” code.

So, the next time you want to report to me that the code doesn’t work, make sure you have already done some investigation and collected some information to share with me. Even if it is not your code, you should be smart enough to collect enough information to know where the problem is, and most importantly, know based on your debugging where to delegate the information to. I receive tickets for defects and bugs from end users and QAs, but I should receive “debugging information” from developers after they receive the bug from an end user or QA. Otherwise, if the developer is just passing around the bug as reported originally, or worse, as he discovers it on his system, then he will be as useful as another GPS in the same car.

Always debug the problem. Check out the logs. Try to reproduce. Collect more information from the user who reported the problem. Treat this bug as your bug until you cannot do anything anymore and have to delegate. And if a fix is pushed out and you countered a problem, try to see if it is really the same problem (under ALL isolated conditions) or a new one. Most technologies have great debugging tools and API as well as meaningful messages. And never say “it doesn’t work” or “it still doesn’t work” EVER again.


Tags: , , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: