There was humorous sort of "argument" that erupted over what was essentially a product placement article. Basically, one of the DARPA driverless car competition teams ran into trouble because their code was not freeing C# pointers from an event listener data structure, and so the car would exhaust memory and then go off the road. They used a commercial product to find the problem, and provided a testimonial. Of course, it was linked on Slashdot and people quickly divided into a few camps, the "how could they be so stupid/naive!" camp, the "C#/Microsoft sucks!" camp, and the "Hey, this is just an ad posing as an article" camp. Leaving aside the hardliners for a second, I thought about the underlying problem a bit. I certainly think of this type of memory leak as a "rookie" mistake, and this team was probably not made of up top-notch programmers, but top-notch vehicle designers and AI people who were good enough coders to get to the finals of a serious competition. There is a big difference between people who write code as their primary objective, and those who see it as a means to an end, so I don't fault them for making the kind of mistake they did.

I do however take issue with the follow up comment posted by the software vendor:

There seems to be a lot of criticism of
the Princeton team, both here and on Slashdot, for missing such an
“obvious” mistake. If I had written code which managed to drive a car
9.8 miles through the desert I would be incredibly proud. I feel that
this vitriolic criticism of a group of undergraduates who had the
gumption and the vision to go out there and create a software and
hardware solution to drive a car across a desert is very disingenuous.
They had a hard deadline and did an incredibly good job given the
constraints on their time and budget.

They had tried to fix
the problem they were facing and had put in a workaround so that they
could compete on the day. Unfortunately, they had not used a profiler
which could have shown them the underlying problem.

For me the
story is a great illustration on why having the correct tools when
programming is vital – regardless of if you are developing in C, C++,
C#, SQL or any other language. At <company> we are committed to
providing these tools and ultimately, due to the attention this article
has had, I believe that we were right to publicise it and that
hopefully the message that it is easier to succeed if you have the
right tools is getting through.

I like and agree with everything up until the " the story is a great illustration on why having the correct tools when programming is vital" part. In fact, I think it's just the opposite. Going back to my "Tools are not Techniques" theme, focusing on the success that this particular tool had in this situation obscures the fact that they didn't apply the proper techniques to finding the problem. The profiler helped them see what was leaking, but I would guess that some regular debugging techniques, like making the destructor or finalize() method print ouf some info so that you can see which objects are being collected, would have been just as effective, and would have cost nothing. The fact that they lacked the techniques at the time they needed them only reinforces the notion that while tools can give you efficiencies and data that might otherwise be unavailable, but they are no substitute for knowing how to investigate a problem.