Donohue and Levitt are somewhat famous for their bold claim, published in the May 2001 edition of the Quarterly Journal of Economics, that legalized abortion has reduced crime.

The Economist just put forward an amusing update that discusses a Federal Reserve Bank of Boston working paper and counter-claim that is based on a re-test of the data and analysis of the computer code used by Donohue and Levitt:

Messrs Foote and Goetz have inspected the authors’ computer code and found the controls missing. In other words, Messrs Donohue and Levitt did not run the test they thought they had—an “inadvertent but serious computer programming errorâ€?, according to Messrs Foote and Goetz

Fixing that error reduces the effect of abortion on arrests by about half, using the original data, and two-thirds using updated numbers. But there is more. In their flawed test, Messrs Donohue and Levitt seek to explain arrest totals (eg, the 465 Alabamans of 18 years of age arrested for violent crime in 1989), not arrest rates per head (ie, 6.6 arrests per 100,000). This is unsatisfactory, because a smaller cohort will obviously commit fewer crimes in total. Messrs Foote and Goetz, by contrast, look at arrest rates, using passable population estimates based on data from the Census Bureau, and discover that the impact of abortion on arrest rates disappears entirely.

I look forward to the question of this programming “error” being addressed by Donohue and Levitt. It does not seem to refute the premise of their conclusion outright as much as question the methodology and provide an opportunity to fix a control and re-run the tests themselves.

The big question, of course, is still whether there are controls that have a direct relationship to reducing crime and at what cost.

On-Track has released their annual report on the top ten data disasters. It is a serious business, and OnTrack has built quite a reputation for saving the day(ta):

10. PhD Almost an F – A PhD candidate lost his entire dissertation when a bad power supply suddenly zapped his computer and damaged the USB Flash drive that stored the document. Had the data not been recovered, the student would not have graduated.

He must have been in a state of shock — “Teacher, the electricity ate my homework”.

4. Drilling for Data – During a multi-drive RAID recovery, engineers discovered one drive belonging in the set was missing. The customer found the missing drive in a dumpster, but in compliance with company policy for disposing of old drives, it had a hole drilled through it.

Can we please see the top tep without the remarkable recoveries included (just the failures)? That would be more interesting, I think. Or, as the infamous WWII story goes, if you are going to better-protect your pilots you should review planes that were shot down rather than just the ones that returned.

Don Norman, former VP of Apple’s Advanced Technology Group, posted a comment on TedBlog about a common failure of Apple designs:

But now let me tell you my pet peeve: the on-off switch of both the regular iPods and the Shuffle. Historically, one thing Apple has always gotten wrong – on all products, big and small — is the power switch (I even wrote a book chapter about this once). The iPod on-off is a mystery to behold, a mystery to explain to others. The Shuffle is even worse. You have to slide a very-difficult-to-slide slider down some unknown amount. It has two settings, but no marking to let you know where you are. Actually, it has markings but they have zero correspondence to the switch setting. You know, this is NOT a tradeoff. Having a little mark on the sliding part and corresponding labeled terms on the fixed case would be trivial to do. Make usage smoother and easier. Cost no money. Bah.

Why is the slider so hard to slide? Their Industrial Designers seem not to have heard of friction — the fingers slip over the nice smooth surface, while the switch remains stationary. Finally when I finally squeeze really hard, the slider does move, but too far, to the wrong position. And those blinking lights. Secret codes that mean who-knows-what. It sometimes takes me 5 minutes to get my Shuffle to start playing, me continually sliding the switch up and down, pushing various buttons, watching lights go on, blink on, flash, turn various colors. All meaningless.

Just the other day I was reviewing racks of servers with bright warning lights. “What does that indicate?” I asked the admin responsible to see if they could decipher the code. Unfortunately, I was told something similar to what Don might have guessed, “no idea, but they seem to come and go.”

All the way from the personal mp3 player to the datacenter, the sole LED has become a cornerstone of messaging and yet no one seems to be very worried about learning how to interpret its meaning. The old-school hex number codes were one thing, but it seems like an amber or green light blinking erratically is almost guaranteed to be ignored.

To be fair, Don could have mentioned that Apple does provide an iPod shuffle reference card to break the codes.

I like the Check battery code: if you do not see a light, there is no charge. Ah, yes, and if your shuffle is wet, it must be raining.

Corante has an interesting warning about Podcasting security. It seems that if you’re not careful, someone else might be registering your podcast for you and (as a man-in-the-middle) waiting for an opportune moment to turn off their link and then blackmail you.

Ease of adoption strikes again. Authentication of an RSS feed might be a good idea, even if it adds a moderate amount of flexibility. Podcast certificates anyone?