Advantages of pair programming and or good code review

I had a little problem with some code that went live an through a NullPointerException, causing various problems in the production system.  It was far from a disaster but not great that such a thing should happen.  Additionally The error was hard to track down to its source.  When I did track it down I found the problem described in this post.  As soon as I saw it I knew that was contributing not only to the issue but causing additional problems.

The key here was that in testing which I reviewed with the author of this code everything was OK.  I would like to have unit tests for everything testing every possible issue.  But we don't.  Its not always practical, its not always easy to know the issues ahead of time.  We should, I should insist on it.  Would projects that are running late run later, most definitely.  Would we have less problems once they went live, almost certainly.  I just don't have the man power right now to get everything done, and remember I am not the boss.  My superiors are all non technical.  They want things done yesterday. They don't understand why it isn't ready just that it isn't.  As long as I can rule out critical bugs it works in my favour to get things rolled out and running, and solve the minor issues as the come up.  Its inefficient and its bad practice.  Solution, if you are in the same position as me then get a bigger budget and hire and extra programmer or two.

With or without the extra man power there are two possible methods that can be used to avoid at least some of the issues that come up when going live with new code.  Pair programming and code review.  At my previous place of employment we used both to ensure as few mistakes as possible.  Pair programming is an interesting method, because it requires one computer and two people.  One is in the driving seat and the other sits next to them and contributes.  Anyone familiar with Agile or Extreme Programming will be familiar with pair programming.  When it works its great.  The time lost by having to programmers work on one piece of code is gained back by having higher quality of code, that is easier to maintain, and with less bugs.  Even things like the write / compile / test cycle is improved by having less syntax errors (due to them being spotted by the one not doing the driving).  Ideas are generated and turned over faster.  When it comes to maintenance or fixing the bugs that do get through having two people that worked on the code originally can be very helpful.  If one is off on vacation or sick, or worse has left the company, the other is likely to be around.  This extra ownership of the code is so helpful in these situations.

An old colleague of mine envisioned people rotating the pairs reasonably frequently, lets say one person worked with one pair in the morning and another in the afternoon.  The more people you have the more possible pairs.  This could mean even more that two people have some ownership of the code.  Switching pairs around will give people the opportunity to take a break from each other, which is often needed in some cases, and to find really constructive and destructive pairings, to be either encouraged or discourage in the future.  An additional benefit of pair programming is the lack of other distractions, you cannot be sitting in front of some code when working with someone and then suddenly check your facebook/gmail/twitter.  You will certainly need more breaks, but you wont spend real coding time wasting it on the internet.

Where it breaks down is when you do not have many people it can still be done but without the variance of a large group.  The number of possible pairings is n(n-1)/2 (triangular numbers), so in smaller groups this is limited.  Additionally not all possible pairs work.  I was often paired with weaker coders which meant I was doing most of the thinking.  It was also frustrating for me not driving because the driver was working so slowly.  In some projects I was working with one other programmer and we would spend some time working on the same code and other time working separately.  The other coder would frequently get stuck and ask to do some work in a pair.  This was code for either me working and explaining what I was doing to his code as I went along, or sitting behind him growing ever more frustrated as I told him what to do.  That was a particularly nightmare case.  Other pairs that I worked with were great.  We thought alike, solved problems quickly together and saved time exactly in the ways mentioned above.

Code review is a lot more annoying but is a great final barrier before moving to production.  I would often work with another coder on some code, then later go to someone more senior than me to be my pair for the installation.  This meant that I had to explain all changes to the senior person, who would look over the code for any glaring errors, and understand the changes that I had made.  Installation was made safer by having someone look over my shoulder making sure that I didn't do something stupid in production.  The reason its annoying to do is again because it means taking the time of someone senior to go over something you know well again.  If you want to get something in to production quickly it can be really annoying having someone asking you to justify every line of code.  However in the long run this is the safest way to do things.

If you haven't tried pair programming, try it, even for a couple of hours a day.
Happy coding.

Passwords and Security (cont)

And just like that here we have it
https://browserid.org/
an attempt by Mozilla at unifying your login.  This is exactly whats needed.  One login for all sites, cue Lord of the Rings reference.
There are many sites like banking sites that may not work with this straight away, especially as my bank likes me to change my password every 2 minutes. see previous post.
But with initiatives like this I can see things moving in the right direction.
Google goes a long way towards this, once you are signed in to Gmail you are signed in to all Google products. However that is limiting in that you may want to use something other than Google on the web.

Safe surfing...

Passwords and Security

I have too many passwords, way too many. Its dangerous I am signed up to many websites, often using my email as a username. I am careful though not to use my the same password for my email as I do for the websites where my username is my emails address. http://bit.ly/rqYTu0 XKCD sums this up quite nicely.  I am a big fan of using google account /facebook /twitter logins for other sites.  This makes perfect sense to me.  I only need one strong password for my gmail account and google with authorize my login to other sites. I really hope many sites pick this up, the internet will become a much safer place, though could force some people to get accounts with services they do not want. The other day I almost signed up to facebook as it was the only way to log in to a site.  I didn't in the end so I never got to use that site, but doubt many people will be in this situation.

This was not the main purpose of this rant.  There are some sites, mainly banking, and also at a previous company where you have to change your passwords every 3 months.  I just think this is totally excessive.  No one takes security seriously at this point.  Every time I have to change my password one of two things happen.  I forget my password and I get locked out or I have to write it down on paper and leave it next to my computer.  Additionally in order to try to remember it I have to pick something easy to remember.  I am not the only one that does this.  That being the case the very process used to create more security is actually creating less security.  So Sysadmins I beg you, stop this there are better ways to increase security.  Insist on very secure passwords that never change or use something like and RSA secureID key.  I admit that they are not always practical measures but at the same time they are better than this pseudo secure method of changing passwords every 3 months.

/rantover

JVisualVM - Java's hidden monitor and profiling tool

There are a few different ways of profiling your Java application.  One is using the -prof switch when calling running a Java app.  This will output a profile file when the app is terminated.  Another is a third party app like Yourkit.  Yourkit is great, but you have to add a something to the commandline and after 30 days full free trial is its super expensive.

Finally in recent editions of the JDK there is jvisualvm.exe.  Make sure you have the JDK and not just the JRE.  locate the install directory and find the bin directory.  There you should find the executable.  Once you open it up you can go to tools and add some additional plugins.  On the left hand side you will see the available JVMs that are connected.  The good thing about this profiler/monitor is that you don't need to add anything to the commandline like you do with Yourkit.  In your kit you have to add something to connect to that yourkit agent.  Here it just connects and you can see all the JVMs running.  Each instance of Java should run in a new JVM so you can run and view many different programs at once.  It gives you a basic view of the memory and processor usage along details about calls to GC and the number of threads and classes being used.  Additionally you can run a profiler to which will sample the application and give details of either cpu or memory usage.  This is extremely useful in finding memory leaks or in my case optimizing your code.  I do a large amount of number crunching which tends to use a lot of memory and cpu, using jvisualvm I have reduced the amount of memory used and made the whole process more efficient.  There are other features that let you view information about classes.

I came across and a problem when running jvisualvm the other day.  The executable ran and but it did not detect my running application. I ran an old version of my application and found that it was detected.  In the end I have discovered that for some strange reason the java executable has to be running with code located on the same drive.  Its very strange but seems to be the only solution I am aware of.  If anyone else has seen this problem let me know, especially if you solved it in another way.  As usual drop me line if you have questions that I haven't answered in this post.
Happy optimizing.

Excpetions - if you haven't caught on then you should try to

I am sure this has been said before but I came across an error that occurred yesterday.  I was told the code was working.  For the most part I could see that in the staging environment it was working just fine.  Sunday comes around.  My install day.  I check the staging environment.  I find that there is a null pointer exception.  The code crashed at a strange point.  With some deduction I realize where the error is coming from.  A method was called on an object that was clearly null, hence causing the exception.  The object that caused the exception was instantiated on the line before.  So no doubt there.  I the method called on the line before returns the object in question so I look at the method, which happened to be in a different class.  I see:

public SomeObject badMethod(InputObject obj){
  try {
       <code some of which that could cause an exception..
          including declaration of SomeObject 
          and return of the instantiated object>
  }
  catch (Exception e) {
     return null;
  }
}

Two big problems with this, possibly three.  The minor of all of these is that so much code is in the try block.  I am not sure if this is wrong, but at the same time it doesn't look right mainly from a maintenance point of view.  I had to delete the try and catch lines to find out which line of code require the exception handling, thanks to Eclipse that bit was simple.

I found out that the exception was actually a ParseException.

TIP #1: When using try catch blocks to catch exceptions, catch the specific exception.  Always be more explicit when you can.  Code is more understandable and you have the specific exception object available to you in the catch block.

The really big problem was how this was handled.  Theoretically I have no problem with returning null from a method.  However if you use a method that could return null that value must be handled.  Sometimes it is better if the method throws an exception instead.

TIP #2: If the method could return null you must test for it.  Otherwise you will end up with a nasty NullPointerException

In my case I ended up with an unhandled NullPointerException instead of a ParseException.  I had no further information about this as well.  This brings me to another point, at the very least you want to have the line

e.printStackTrace();

in the catch block.  At least then you can track the exception properly.  Better still use a logger, and add a little message of your own perhaps with some variable values printed so that you have an idea of what went wrong in your log or on your console. With most loggers you can add the the exception itself as an argument and the logger will handle outputting the relevant information from it.

TIP #3: Use a logger to print a sensible message from the catch block.

In this example the there was no real exception handling in the code.  The catch block just returns a null which is not handled in the calling code.  My solution in this case was to add a sensible logging line and throw the exception again.  This way the exception is passed up the stack.  The key here is that it forces the calling method to handle this exception.  In this case that works, I needed an extra try catch block, but the error will be handled better.  Now the parse exception will be passed up through the calling stack and the method will now handle this error correctly.

TIP #4: Handle the exception, its not enough just to print the stack trace or log the error.

Conclusion:
The tips I have presented here are very important when dealing with exceptions in Java.  It is too easy, especially in Eclipse which does so much for you, to leave the printStackTrace() in there and not do anything else.  But they must be handled.  Learn to use them problem and exceptions will be your friend.  Errors will be handled correctly and the code will run more smoothly and hopefully be a little more readable.

Happy coding.