The First Rule of Programming: It's Always Your Fault | Hacker News Reader

The First Rule of Programming: It's Always Your Fault

codinghorror.com

25 pointssharksandwich14 comments

Another similar rule I like to follow is that if a user of your site cant figure out how to do something, it is your fault not theirs

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.

Agreed. A project I worked on in grad school involved developing a thick client (Swing) for a large corporation. Well, we pushed the envelop with Swing, and it was several times where a bug was actually in Swing, and we had to find a workaround in our code while we waited for Sun to fix it.

But on the flip side, everytime we saw something weird happen, our knee jerk reaction was, "Its a bug in Swing". And our project leader would look at us and say, "Java works". His philosophy there was that if your basic assumption is that the tools you are using are broken, you can never get anything done! Start by assuming you made the mistake, and work away from that point.

I did a Swing project soon after Java 1.3 came out and kept finding odd bugs where the behavior of the code directly contradicted the behavior in the JavaDocs. My experience was basically that if you didn't do things exactly as they did in The Java Tutorial, chances are it wouldn't work. Or it'd mostly work, but with weird edge cases when you did something unexpected.

I asked my QA manager about this, and he said that the word on the street was that Java 1.3 was not QA'd. They just made sure that the tutorial worked and pushed it out the door.

I've had similar experiences with Java AJAX frameworks. The basic stuff from Sun (JavaEE, JSF) seems fairly robust, as long as you use it in the intended way. But many of the add-ons like Facelets, A4J, RichFaces, etc. are made by small 2-3 person startups, and they don't QA or document their code at all. Moreover, their code frequently makes functionality in the base JSF layers break (eg. you have to use ui:repeat instead of c:forEach with Facelets, and then you have to use a4j:repeat instead of ui:repeat if you add A4J). Maybe that's changed since they were bought by JBoss, but it's something to keep in mind whenever you use bleeding-edge libraries by small teams.

So I'd amend that: start by assuming you're wrong, but if you can't find anything in your code, look at your dependencies in order of least-used -> most-used. Chances are, software like Python or Apache or Java has been fairly well-exercised, and most of the bugs have been worked out. But there's no reason to believe that JPartTimeOneDeveloperLibrary is any better than code you write yourself, and if you use untested projects like that, you should budget time to look through their source code and debug their problems and send in patches.

Unfortunately, sometimes managers get it into their head that a 3rd-party library is more reliable than it actually is, often because the vendor has the chutzpah to charge a hundred grand for it, and they mandate you use it. This should be considered a bug in your manager, but unfortunately there's no fix for that...

Whenever I run into a frustrating "bug in the compiler" type problem I find it's useful to take a walk or revisit the problem again the following day.

Many times my mistake becomes obvious right away.

On rare occasions I still find myself falling into the "I'll get it soon" bug-seeking trap. That evil state can keep you spinning your wheels for hours.

I've a rule to help recognize it: If I start spouting frustrated profanity, I have to step away from the screen for at least an hour. It's amazing how obviously simple the solution is on my return.

I am pretty sure that every trainee and junior programmer I have ever mentored has come to me with a "bug in the compiler". I always try and find the gentlest way possible to tell them that it's unlikely that there is a bug and if there was then in all probability their more experienced colleagues would know about it.

Usually however it is a good start point for revisiting the topic of program structure and the tricky question of "state". A quick re-write of the offending routine usually removes the "bug".

I live and die by this. I've spent a number of years muttering to myself "It's not the compiler. It's not the compiler." (Though, strictly speaking, these days "It's not the interpreter.")

And then I remember that day that a coworker tracked down a microcode cache-sharing bug on dual processor servers that he notified Intel about.

Always? I just returned from fixing a problem. A system call for UDP connection wasn't working. It worked yesterday. I could, however, ping and ssh over the network interface.

I tried an earlier branch. Same problem. After that, I replaced the NIC, rebooted, and everything worked.

Sometimes it really is the hardware/library/compiler/... There was probably a lot more investigation I could have done before going to that level (as the author suggests) but in this case it was most efficient to try replacing the card early and identify/eliminate it as the problem.

Remarks from 2 mentors I have never forgotten:

1. Everything worked fine. You came along and did something. Now it doesn't work. I wonder if it has something to do with what you did.

2. I seriously doubt that the operating system, which has worked perfectly well for 20 years, suddenly and unexpectedly messed up on the exact same day you arrived.

A remark from 1 mentor I have never forgotten:

1. If you can't think in base-8 you CAN'T be a programmer!

so I set out to write a program that would think in base-8 for me...

I think someone's watched A Bug's Life recently.

http://www.youtube.com/watch?v=NWSrwEYJBrg

Reply on news.ycombinator.com