The only thing that really matters in software development.

Catchy title? I mean it. After 25 years of programming, the only thing that really matters in software development is if a company understands the project triangle. That from the three variables scope, time and resources you can only define two. There are two kinds of companies. Those that understand this and those that don't. Everything they do flows from there. This is what really matters about software development.

Update: There are a lot of other factors, probably people being one of the most important (think "Peopleware"). Without understanding the Scope-Time-Resources triangle your development won't work. It just can't. You can screw up by chosing the wrong architecture, or methodology, or screw up during requirement engineering or with the wrong language for the problem.

But from my point of view this triangle is like gravity. If you ignore gravity, all else will fail.

Unboxing as a Java Interview Question

Sometimes I ask an unboxing question during Java interviews. "What can happen with unboxing? See this code:"

Integer i1;
... 
// do some things with i1;
...
int i2 = i1;

The thing that can happen is that i1 is NULL which will result in a NullPointerException being thrown.

"What is the problem with the NPE here?" There are several ones. The big one is that developers search for dereferencing variables (think ".") when seeing a NPE. The line

int i2 = i1;

does not have a dot, the trained eye of a Java developer has problems to see the NPE there (if he didn't encounter the bug before).

"What would you have done instead, if you would have been the Sun developer designing the unboxing feature?"

Possible answers are:

  • Set i1 to the default value if i2 is null, 0 in this case (null being the default value for Integer)
  • Throw an IllegalArgumentException
  • Throw a ClassCastException
  • Throw an AutoUnboxingException (my favorite)

It's more about discussing design and programming decisions than getting the right answer from the candidate. With questions like this you can see how defensive a programmer can think, how he writes maintainable code and how good his micro-architecture design skills are. Often there is a dialog between the candidate and me about good design, error handling, exception handling and error messages.

What would you do?

Thanks for listening.

As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled)

Update: This code will throw an NPE too - obviously - but from reading the isSomething() line in a large app it might not be that obvious.

public class Test {
	
	public static void main(String[] args) {
		if (isSomething()) {
			System.out.println("Something!");
		}
	}
	
	public static Boolean isSomething() {
		return null;
	}
}

Bending Java: More readable code with methods that do nothing?

From the category "Bending Java near it's Breaking Point" or "What a stupid but interesting idea". I like to explore ideas in Java that are inside the language spec but outside of common usage or style guides. I think Java has a lot more to give than what people did the last ten years. Before dumping Java perhaps we should reconsider some of the "common wisdoms" about how to do things in Java.

My last post on beautiful Java, and why to never use String 😉 got me flamed like I haven't been flamed since alt.amiga.advocacy times. The idea was to provide wrappers around String like Name to achieve several things: Have better typed method signatures, have a fluent interface and to better convey meaning.

Customer customer = new Customer( name("Stephan") );
...
Customer(Name name) {
...
}
...
public Name name(String value) {
...
}

The flames were mostly about creating lots of small objects, which people claimed are unnecessary and unmaintainable.

An alternative implementation would be:

Customer customer = new Customer( name("Stephan") );
...
Customer(String name) {
...
}
...
public String name(String value) {
 return value;
}

This implementation doesn't achieve the same things as the solution before, but there is no new object necessary, only a new method.

But still the line Customer customer = new Customer( name("Stephan") ); is more readable than Customer customer = new Customer( "stephan" );. The Hotspot JIT should optimize the method calls away so there is no performance penalty.

A better idea? Or still too repulsive.

Thanks for listening.

As ever, please do share your thoughts and additional tips in the comments below, or on your own blog (I have trackbacks enabled). This line is shamelessly take from Daniel Tenner, who writes a really excellent blog.