It was a normal day. The sun rose, birds were singing and everything seemed to be going fine until Kaboom ! A bug appeared in the live environment. Things turned downhill from there that day. But we are more interested in how things got fixed so lets focus on that.

An investigation of the code revealed that the bug had crept in because of a minor mistake. A variable was referring to the wrong column index on a table. ‘Hmmm… simple fix’ I thought. I told my manager it would not take more than 5 minutes to do. ‘Its a one line fix’. Mistake.

There were loads of other things to do after fixing this bug. This is what I ended up doing over the next 4 hours.

• Analyze if any other code flow would explode.
• Code the fix – This only took 5 minutes as expected.
• Move fix to DEV
• DEV server crashed. Great. Fix this and get DEV up and running.
• Test fix
• Export the old data before the fix
• Export the new data after the fix
• Compare new data with old data and verify the result for each column (Wrote a small program to do this).
• Move fix to PROD
• Close the bugzilla bugs and fill in a lot of bug details
• Inform PROD users about the fix

So ! There we are. All done. Loose ends tied. But at the end of the day, I had not set the right expectations when I went about fixing this problem. When you say things like ‘It will be done in 5 minutes’ and ‘It is a one line fix’, you need to remember that to an end user / manager that might sound something like ‘It will start working again after 5 minutes’. But that is not the case. Well… a manager with a technical background would be more understanding but that is not my point.

Sometimes there are things you cannot put down in writing when you provide an estimated time to fix stuff. I find it is always better to say ‘Sometime by Tuesday noon’ instead of ‘One line code change / 5 minutes’. It sets the right expectation and you don’t have people asking you ‘Its not done yet !?’. Explaining your work is sometimes more important than the work itself.

Ever visit sites like topcoder.com and solve a problem or two ? No ? You should and do so regularly. It will help find tune your programming / design skills. This is because solving the problems requires going though the following thought process

1. Understanding the problem.
2. Thinking up a solution that covers all use cases.
3. Executing your thought process through code.
4. Testing.

Now as simple as that sounds, it is not so easy to get right. Especially when you are competing with thousands of fellow coders for time. And when time is a constrain you usually select the first solution that comes to your head, which might not necessarily be the best. So there is that risk of your code timing out even if it is following the right logic. I would love to delve into a problem right about now and throw in some examples and illustration, but you get the point.

When the thought process that we follow is not well defined and we lose focus, it often leads to buggy code. Don’t believe me ? Here are some bugs I caught in a code base on a recent project.

Bug 1

Bug 2

Bug 3

There were more bugs identified after development than what is listed here. But what I wanted to highlight was that the problem was introduced into the system due to lack of focus and clarity of thought. Well, more often than not anyway. Other times the bug sneaks into the system because the number of test cases to test a method were not sufficient.

Have a look at this google research blog post about broken binary search and merge sort algorithms for example. They pretty much have the same bug as the date calculation bug that I highlighted in a different post. We are all prone to creating bugs, but we can minimize the number of ones we introduce into the system.

So what have I learned from introducing bugs so far ?

1. As long as you keep your skills sharp and practice solving problems, the number of bugs you introduce will reduce. I try to visit sites like topcoder.com or codingbat.com whenever I find the time.
2. Learning from other’s mistakes and best practices can save you tons of time.
3. Try not to cram in your work within X hours. This tends to focus the effort on finishing the code on time instead of writing it neat and bug free.

As always its easier said than done. But hey, its never too late eh ? As for finding the bugs in the first place…

1. Use a tool like FindBugs after you are done coding. You will be surprised at how many problems turn up.
2. Try to maintain a code coverage of at least 80 %. Tools like Emma can help you track this.

I ran into another sweet little bug that I thought I would share with you. This one cropped up after it passed a few tests. See if you can spot the problem. Without further delay here it is

Problem:

A record needs to be inserted with a new identity number. This number is obtained as the next maximum ID value from a set of elements in a XML file. The following code is supposed to obtain the next ID from the XML. Lets skip the XML related code since that just adds clutter.

Code:

int max = 0;
for( DataType data : someListFromTheXml )
{
    if(max < data.getId())
    {
         max = data.getId()+1;
    }
}
s_logger.info(" Max id: " + max);
return max;

See anything wrong with it ? Its got a pretty big flaw. The logic works only for odd number of elements. When the number of elements is even, it fails. Here’s an illustration

Test cases:

public class Test
{
    public static void main(String... args)
    {
        int [] input1 = new int[]{1};
        int [] input2 = new int[]{1,2};
        int [] input3 = new int[]{1,2,3};
        int [] input4 = new int[]{1,2,3,4};
        Test test = new Test();
        test.go(input1);
        test.go(input2);
        test.go(input3);
        test.go(input4);
        test.go(input5);
    }
 
    public void go(int [] input)
    {
        int max=0;
        for(int id:input)
        {
            if(max < id)
            {
                max = id+1;
            }
        }
        System.out.println(" Max id: " + max);
    }
}

Here’s the output:

Max id: 2
Max id: 2
Max id: 4
Max id: 4
Max id: 6

The logic incorrectly assigns the max to id+1. Instead it should have stored the current max and returned max+1 at the end of the loop. Sigh.

In hind sight a Xpath expression would have done nicely here. Something like max(/Parent/child/@value)+1. Still that is no excuse for the faulty logic

I came across another silly little bug today. Take a look at the code below (assume ‘days’ is a parameter and that this snippet is part of a larger function)

Date now = new Date();
long nowMillis = now.getTime();
Timestamp nowTimestamp = new Timestamp(nowMillis);
long future = 3600 * 24 * days * 1000;
Timestamp expiryTimestamp = new Timestamp(nowMillis + future);
System.out.println(nowTimestamp);
System.out.println(expiryTimestamp);

Can you tell what is wrong with it ? What the code intends to do is to set an expiry timestamp to an element – X days from today. A caller called this code snippet with the value 5. Well there is nothing wrong so far. Here is the output

2010-04-27 10:37:10.497
2010-05-02 10:37:10.497

So then came along an element that needed an expiry of around 40 days. The caller calls with the value 40. Guess what the output is

2010-04-27 10:38:43.372
2010-04-17 17:35:56.076

Umm… so the expiry date is *before* the current date. Super. So what is going wrong ? The value of future in this case is -838967296. Although future is a long type, the data type that is being calculated to assign a value to it, is int. An int cannot take anything more than Integer.MAX_VALUE (2147483647).

If future had been calculated correctly, its value would be 3456000000. Instead what is being presented is the wrapped around value obtained after adding the remainder to Integer.MIN_VALUE.

I guess that just goes to show that if it aint broke you may still need to fix it later. Of course that depends on what your definition of ‘broke’ is

I was testing an application today and came across a bug. A screen had some CRUD operations on a resource. The problem was, whatever I did, the system would perform the operation and tell me that the resource already existed. This left me scratching my head for quite a while. I add a resource and it says it already exists and then adds it. Delete and update also do the same.

So the debugging process started and I sat down with eclipse to get to the root of the problem. I verified that indeed the CRUD operations were reflecting in the persistence store. Then I came across these magical lines of code

public static final String S_SOMETHING_EXISTS = "something.already.exists";
public static final String S_SOMETHING_ADD_SUCCESS = "something.already.exists";
public static final String S_SOMETHING_DELETE_FAIL = "something.already.exists";
public static final String S_SOMETHING_DELETE_SUCCESS = "something.already.exists";

This left me smacking my head. It should have been

public static final String S_SOMETHING_EXISTS = "something.already.exists";
public static final String S_SOMETHING_ADD_SUCCESS = "something.add.success";
public static final String S_SOMETHING_DELETE_FAIL = "something.delete.failed";
public static final String S_SOMETHING_DELETE_SUCCESS = "something.delete.success";

The bug was introduced when I copied the first constant and pasted it three times. I forgot to change the keys . My point is, most of the bugs that I see introduced into the system are due to silly mistakes like the one above. This is where tools like FindBugs (which can be extended with your own rules) and CheckStyle and other bug finder / code review tools come in handy. A human code review is also a great tool. This little bug served as a reminder as to why we have such tools. To a developer this bug might seem small, but wait till an end user sees the message and says ‘What gives !’.

Before you can go ahead and take the real Sun Java exams, you need to know some of the pitfalls that have plagued several test takers. Here are a few pointer

Do not buy a voucher before you are prepared to take the exam:

Often some candidates like to follow this approach hoping that the purchase of the voucher would force them to learn within a given time period. On the contrary this adds additional pressure to your preparation, since you need to study the objectives before the expiry date. Some candidates have lost money misinterpreting the expiry date on the voucher. Be wary of the MM/DD/YYYY Vs DD/MM/YYYY formats. Which one does your voucher display ?

When the candidates finally find that they have no more time to learn, they post a message on a forum that reads something like ‘I have voucher for exam X for a discount of Y%. Please call me to buy’. Remember, you are a candidate, not a voucher reseller

Material made available to you inside the exam room:

Prometric centers will not provide you with pen/paper/pencil at the time of the exam. You will be given a plastic sheet and a marker/felt pen. You can jot down on the plastic sheet with the pen.

Mobile phones, PDAs, and other object that would allow a candidate to cheat are not allowed. Also make sure that once you are ready, you book your exam slot in advance. This ensures that you dont spend anxious minutes waiting to buy one just before the exam.

Beware of drag and drops:

All Sun Java certification real exams run on a managed software. This software has a user interface where some questions require that you drag elements and drop them into their appropriate places. Beware though, once you answer a drag and drop question you cannot review its answer again. Which means if you do answer the Drag and drop question, when you try to review the answer next time the answer will be lost / reset. If you want to, you can jot down the drag and drop answer on the plastic sheet given to you and review it later.

Code analysis:

It is important to analyze the code presented to you even before you attempt to find the solution. Scan the entire class for well known problems before continuing your analysis

• Are non-static variables referred from a static context ?
• Are there infinite loops ?
• Is there a compile time error ?
• Are method overridden correctly ?
• etc etc…

Once you know how to scan for such patterns, answering the question will become easier.

Am I ready ?:

So when do you that you are ready to take the exam ? Thats a tough one to answer. There are candidates that get 50% on the mock exam but pass the real exam with flying colors. Then there are the ones that pass mock exams and fail the real one. The latter group is rare. At the end of the day if you know what your weak points are and you are confident that you can strengthen them, go for it !.

Back to home