It came to me tonight. A simple idea, really.

All scientists should submit their papers where they are likely to be accepted. Oh! We all need a critical review. Sometimes we even need to be told to rewrite our paper and come back. However, scientists should not play Russian roulette.

Sending a paper to a venue where you…

• need to include or exclude certain words or concepts;
• have a good chance (say 50%) to see your work turned down (irrespective of this quality);
• must cite certain people;
• have to exaggerate your results;
• must force yourself to be more fashionable

is just wrong. We should never do it.

We should work hard. Do our very best to write excellent and honest papers, then ship them and have them published (after some revision). This should be the normal process. Period. Nothing more, nothing less.

We need less boxing, more science.

Disclaimer: I have had good luck getting my papers published this year, so I do not write this post out of spite.

In a comment to my unit testing post, David suggested using property testing. Languages like Java, C and C++ have formalized this very idea as assert instructions. Other languages have the equivalent under different names. You can also manually implement asserts by throwing exceptions or logging errors and warnings.

My experience has been that you should use asserts relatively generously in your code for the following reasons:

• While some fancy tools allow you to run through a program in debug mode and check the values of the variables, asserts help you fix bugs happening remotely.
• Asserts are a great way to document your code. They tell the reader about your expectations.

However, asserts are not as useful as unit testing. Whereas you can write thousands of tests to test your software, adding thousands of asserts to your software may be a bad idea. It makes the code less readable and slower.

The number 1 difference between an experienced hacker and the random guy out of school is unit testing. Unit testing is simple. Anyone can do it. You do not need a sophisticated library. All you need is to run a program that does sanity checks over the different components of your software. The rule is simple:

You should always do unit testing for any kind of code that is supposed to have lasting value.

It is worth repeating: the single most important non-trivial strategy in software design is unit testing. All more sophisticated strategies are usually not worth the cost, and all simpler strategies are somewhat trivial. While you can discover most good coding techniques on your own, unit testing is not something very natural to most hackers.

If you sell software for a living, unit testing is extremely important to keep your sanity. While you cannot provide bug-free code, you can at least provide software that passes some unit tests.

A few hours a month, I like to play video games. I never get very far because I lack when teenagers have in abundance: time. However, I make it up by complaining that in my time, we had 4 colors—when we had colors at all—and a 80×25-pixel resolution, and we programmed our games ourselves in BASIC—if not assembly.

In any case, the Nintendo Wii is a great toy, but mine had recurring troubles with something called the “black screen of death” (BSD). Basically, you insert a disk and the Wii will fail loading it displaying a screen that goes like so: “disk error, press eject.” The first few times this happens, you think there is a scratch on the disk or some dust over your laser. Unfortunately, as times went by, my Wii got worse and worse. Eventually, a week ago, I got a BSD whenever I tried loading any game up.

I am not a man who likes to call up a company or send a product up for repair. However, I decided to call Nintendo. Turns out that they are very nice about it. They gave me a repair order over the phone, I shipped the Wii (for free) and now, 3 days later, I got an email saying that they are returning a working Wii to me.

A few things that Nintendo does right:

• You can call them 7 days a week.
• When you call them up, they do not make you wait with annoying messages like “your call is important to us.” No. They answer the phone almost immediately.
• The support staff does not assume you are an idiot. They do not ask you whether you forgot to plug in the Wii.
• At all times, you can track the repair order with their Web sites, and you receive automated emails.

My experience with Sony and my PS2 was much worse when I got similar problems. They had me call up California and an annoying lady took me on a ride. After 15 minutes on the phone, all she told me was that she was sorry that she could not help me. With Nintendo, there are no excuses. They take charge of my problem. Period.

Before I conclude: why are we still using disks at all? Most games are under 400 MB. I can easily download 10 or 20 such games a year without taxing my Internet bandwidth at all. Storing that much data is not an issue: a 10 GB Flash drive is dirt cheap. If the Flash drive fails, I may have to redownload the games, but who cares? And wouldn’t a Flash drive be much faster than an optical disk (at least for random reads)? I wish I could at least copy the optical drives on a Flash drive and have my game console load it up from there. I could easily put 10 games on a small drive. The Wii has USB ports, so there is no reason why this could not work. Maybe hackers out there even made it work already… any clue?

Update: I got the Wii back today (Friday), while I shipped my unit on Monday night. They changed the disk drive.