Hacker News new | past | comments | ask | show | jobs | submit login

That's funny, because I have always had this notion internally (don't blame the tools, look in your code first), but in a recent project it actually was the tool that was broken more often than not. Consider the issue where:

  String s = (String)(vect.remove(vect.size() - 1));
... throws a NullPointerException, where the code:

  Object o = vect.remove(vect.size() - 1);
  String s = (String)o;
... works fine.

Can you spot the bug? No, because there is no good reason for it to fail. There is no good explanation for a bug like that. And, when it's in expensive proprietary enterprise software you can count on support NOT giving half a rat's ass about the problem.




Compiler problems suck, because you start wondering if the rest of your code will start failing in weird and wonderful ways once it reaches the customer. I've had a fair share of compiler/system library issues in game development; the console SDKs I've used were unbelievably flaky, all the way from compiler, build system, debugger to system libraries and hardware itself. Not fun. For many people it becomes difficult to maintain the "it's always your code's fault" mantra in that situation.


I'll always remember that long night back in 1992 trying to figure out why one of my freshman CS assignments suddenly stopped working when I had finished the features and was just cleaning up the code. It turned out there was a bug in the Sequent Dynix Pascal compiler that caused my program to fail when I deleted a comment. It took me quite a while to figure that out and put the comment back in. :-)

In retrospect it was a valuable lesson. Always use source code control, and check in small changes frequently. That way you can easily roll back in small increments to figure out which change broke something.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: