2010-06-10

Interesting Powers of Local Variables

I interviewed a Java developer recently and he had a very interesting (incorrect) interpretation of how local variables work in regards to method calls.

This candidate understands that when you pass an object to a method, the method may modify the data in that object, so that when you look at that object after the method call, it will have changed.   This is correct behavior.   For example:

public void addData(List<String> values) {
  values.add("data");
}

...

List<String> myValues = new ArrayList<String>();
addData(myValues);
assertTrue( myValues.size() == 1 );


Here's the interesting part.  The candidate believes that if you were to return a mutable object from a method and assign it to a local variable, the changes stay with that local variable.  For example:

public class Foo {
  private List<String> values = new ArrayList<String>();

  public List<String> getValues() {
    return values;
  }
}

...

Foo foo = new Foo();
List<String> myValues = foo.getValues();
assertTrue( myValues.isEmpty() );
myValues.add("data");  // mutate "local" variable

assertTrue( foo.getValues().isEmpty() );  // WRONG

The candidate insisted that there was only a single instance of the List, which made the conversation very confusing.  This caused a long discussion.  In the end, I believe that his thoughts are that local variables have the ability to hold object "deltas" in a way that aren't reflected back to the original object.

Although interviewing candidates is very time consuming, there are moments like this that I find fascinating.  It's very interesting to hear other peoples interpretations on how the language works.

2010-06-03

Code Quality Pushed Aside?!

It's probably a good time to move on when your team decides that code quality is the lowest priority task.  I understand that delivering the software is a very high priority as delivery of this software is how the business makes money.

I don't, however, believe that code quality should be pushed aside in "crunch" times.  When you have deadlines looming over head, that is the wrong time to throw peer code reviews and unit tests out the window.   Yes, you may be able to meet your deadlines and deliver the software, but at what cost?

How much will it cost the business when you deliver buggy software?  Not only are there maintenance costs (ie, the cost of having a developer fix the defect and then redeploy the code), but there is also the possibility of losing customers.  Losing customers may not be a big concern for certain software like browsers, email clients, blog software, etc; but it would be a big concern for software for medical equipment, financial, e-commerce, etc.

My team has continually pushed code reviews, unit tests, etc as a very low priority, especially in times of frequent deliveries.  The continual response is, "we'll have more time to do this and fix our processes later."  I have yet to see this mythical "later."

My team also doesn't understand why we get so many defects back from our QA team.  There have been times where management will require weekend work, to work on nothing but defect fixes.  If 80% of our time here is working on defect fixes, why can management not see that something needs to be changed?

If you're a software manager, please take the time to invest in good code quality practices such as unit testing and code reviews.  You'll be thankful you did.