and this too shall pass...

30th of June 2010, Wednesday - a day I will never ever forget in my life!!!

Our team got a call from an irate customer, who was angry that his data was missing - yes that was a very serious problem!!! Even before, we finished introducing ourselves in the phone call, he started yelling at us. His tone showed, how frustrated he was. If at all, that was a face-to-face conversation, I fear he would have certainly slapped us.

We promised to resolve the problem and convinced him saying we would give him a call in another 30 minutes, after looking into the log files. We searched this log file, that log file and all possible log files for his session, but nothing helped us.. When all these were happening, we forgot about that 30 minutes timeline - he called us after 45 minutes and the music started again.

Definitely, it was not our day :-(

The problem started at 8 pm IST and went on till the next day morning. The user (though he was from USA) was also awake after his day time - that showed how important that missing data was to him. At regular intervals, we called him or he called us.

Almost after 14 hours, the next day, we some how found the reason of the problem. It wasn't an application bug. It was because of a very silly mistake - both by the user and a usability problem on our side. Thankfully, the user was so kind enough to understand what really happened and also realized what mistake he did. We promised to address that usability in our next update.

and what happened next, was a sweet surprise to us all. He started praising us and promised to recommend our software to his clients :-) We are also happy that we learned, a new way to look into similar problems in the future.


The show started smoothly, had lots of tensions/thrills/pain or what ever you can call them as and finally had a very happy ending. What seemed like an end of life a 10 hours ago, turned out to be a good learning for life time at the end.

and we know even this shall pass by...

Alae.. Alae.. Alae.. Alae..

Few months back, when I had nothing to do, posted a blog on Debugging. Few of my friends said it was interesting - not to mention they all have a good sense of humor.

Today, Brian Whaley, a blogger from US, says the afore mentioned post in one of the great articles on the Methodology of Debugging!!!! (Link to his post HERE)

Alae.. Alae.. Alae.. Alae..

Small things aren't really SMALL

Are you are a programmer and having a similar thought as this, in your mind:

"I m not doing anything worth in the application. I m assigned tasks that are of less significance in the software"

If Yes, then I do have something to share with your friend.

There is nothing called as less/no significant feature in a software. Every bits and pieces contribute to the software. Things that appear to have lesser significance, will be of great use to the Users.

Think about the small Start button in the Windows. It realy appears to be very simple. Designing its color and layout would have been a simple task. But whats happening today?

This small button is one among the most widely used UI Components in the World Today!!!!


The same applies for that small text field in the Google Home Page. When designing, the code for this small text field would have been very simple, when compared with the complex search algorithm that was running at the background.

and today this simple text box is the window for all of us to search the Internet!!!

Another interesting fact in the software developement is, at times, the user satisfaciton is inversely propotional to the effort that was put for developement. This might sound funny but it is the truth.

You would have spent days and nights coding for a complex module. Then had done some very simple Ajaxified wrapper for that complex feature. But later, this simple wrapper would make make the software awesome to the user.

When a most important feature in the software fails for some unknown exception reason, a very simple informative error message to the user, can win his trust for your product.

Bits and pieces make a software. Only if these pieces are perfect, Great software can be made.

Then.... to be honest, I really don't know why am I writing this now - may be to pass away the lazy friday evening session.

why to worry when this small post could bring a great change in you!!! [;)]

images from:
www.microsoft.com
www.googleguide.com

Simple ways to make some Quick Money in the Software Industry

I am not really happy to talk about this bitter truth about the software engineering profession.

One of my friends works in a software company for the past 2+ years. All these years his appraisals were just oK - infact very low for a employee like him. So finally he decided not to work anymore for the pea-nuts and started his job hunt. Offers started coming his way and finally he settled for one that paid nearly one and half times his current pay.

On a fine day, he informed this to his manager. Only then the manager realised how valuable my friend is. Now he is ready to pay nearly 50k/annum more than the new offer.

How sad???

Its sad because... two years of service, dedication, passion and blah.. blah.. blah.. (whatever I can say about my friend) didn't get him the recognition from his current employer. He had to get a certificate (so called offer letter) from some other third party to get what he deserved for his current work.

How come now, they are ready to pay this huge amount? Might be, this is what is called as Management steps to minimize attrition of a valuable resource.

Whatever it may be.. now my friend knew the very simple (..yet the best) way to make some quick money from his current employer

1. Just complete the minimal task, expected from him.
2. Improve the technical knowledge i,e. prepare for the job inverviews.
3. Get back with a better offer during the appraisal period.

image from: www.stphilipsumc.org

A simple mistake can take your whole day, away!!!

Today I had to implement a small task related to Windows Active Directory in our product. The base for this had already been implemented in C language, few months ago. Just a wrapper code was to be written in Java, today.

The input for this would be 1. Domain Name, 2. login Name 3. Password.

Everything worked fine if all these parameters were passed as individual texts - i,e. login name without the domain prefix

Its normal for few Windows users to enter the login name with the domain prefix i,e. something like "DomainName\LoginName"

So to handle such cases, I wanted to
1. check if the character '\' is present in the login name,
2. If present, split the string and take the login name alone

This is what I used from Java for step (2)

//*** Assume oldLoginName = domainName\loginName
int i = oldLoginName.indexof('\');
//*** this should be '\\'. Using '\' for better understanding
int l = oldLoginName.length();
String newLoginName = oldLoginName.substring(i,l);

and then pass the newLoginName as the parameter to the native implementation.

Bhooooom!!!! Nothing happened as expected. When I looked at the logs, the input paremeters were right.

So I assumed the problem should somewhere be in the C implentation - especially while converting the Java String to C String.

Analyzed the C code that was written several months ago - Nothing helped!
Browsed through several sites to find if Java to C conversion of Strings had any problem - even this didn't help!!
Starred at my computer monitor for sometime, as if it would obey my words - This toooo didnt HELP!!!

Again thinking the problem should be in conversion, printed the length of C String in the log files.

This time A BIG BHOOOOOOOM!!!

image from www.nowhereland.it

The length was one more than the actual length of login name, that was expected.

Now I got where the problem was. The substring(...) method in Java would return a string extrated from the parent string - from the start Index to the End Index. My falut is that I had passed the index of '\' as the start index which means that character will also be present in the new extracted string.

All I wanted was "loginName" but by a very simple mistake i had extracted "\loginName"

Then why didn't the debug messages in the log show me this???

Very simple - '\' is an escape sequence and the hence the log file had skipped it while displaying.

I love the challenges in the software profession but never thought so much of efforts would be required to understand just two lines of code.

Good learning - alas a very costly one!!!

Debugging tips for New software engineers

I feel Debugging is the toughest part of the software profession. One will have to spend lots of hours breaking the head to trace these bugs. At the same time, the satisfaction that we get when a bug is solved has no limit.

Now with some exprience in the field of software developement, I wanted to share some my learninings with the new software engineers. This isn't going to be a professional detailed procedure for the Debugging process. These are just the things that needs to be done before debugging an unexpected behaviour.

# 1 : Understand the code.

This is the most important tip for the best debugging process. Only when you clearly know what is happening at the base level, you ll be able to trace the cause of the problem. As far as possible avoid BLINDLY copying the code. I m not against reusing the codes, I stress not to use the codes without understanding what its functionlity and dependency.

# 2 : Do not panic.

I see many people get tensed when a bug is found in their code. Bugs aren't bane, infact they are one of the beauties of this field. Everyone puts bug - hence do not panic when there is a bug in the code you had written.

image from : www.inmagine.com

Be happy that the bug had come out at an earlier stage. When it is solved, the users will not be facing the problem again. Always take it as a learning oppurtunity and see to that such things never happen again.

# 3 : Prioritise the complexity and time availability.

This is another important decision to be taken. Carefully analyze the bug and prioritise the bug. Lets have two basic level for this:

Type 1 - Bug to be solved immediately,
Type 2 - Bug that can be solved slowly, i,e. Not an urgent issue and time can be taken for solving the problem.

# 4 : Do Not run for help Immediately.

Yes I really mean this. This is the most common mistake we do very often. When there is a bug DO NOT approach the seniors immediately. One main reason is that this habbit will never make you learn in your own.

Software Engineering isn't a spoon-feeding profession. Your senior will not always be there to solve your bugs - hence it is very important to make attempt to stand in your own.

Hence whenever there is a problem, think, analyze and try to check if you could solve it in your own. Browse the discussion forums in the internet for help. Even if the problem isn't solved, this will make you learn new things related to your task.

#5 : Seek the seniors for Help at the right time.

Well this might be a little contradict to the previous one. If the bug is to be solved immediately, you may spend 15-30 mins (say apprx. 1 hour for type 2 bug) to check if you could solve it in your own. If it takes more time, then approach the seniors for help immediately. Their experi ence will help you or they might redirect you to the right source.

Whats more interesting here is, sometimes while explaining the problem to others, you yourself might get the resolution flashing in you mind. [;-)]

#6 : Discuss with the senior engineers.

This is more important if you had solved the problem in your own. Tell the senior about the problem and the solution you had applied. Sometimes he might have a better solution than the one you had applied. If his is a better one, do not worry about the efforts you had put. A discarded effort is always better learning than the unattempted efforts.

After all life is a learning process. Isn't it? [;-)]