Don’t try this at home, we’re professionals
So I just received the feedback for my last exercises for the Data Structures course. Three mistakes total: I transformed an O(n) algorithm to an O(n2) one (although I spotted that one myself – after I had already submitted my answers, d’oh!) and my lazy-delete linked list was doubly borked: two successive deleted items confused my Purge routine altogether, and the search would stop on a deleted item.
OK, so I admit, I didn’t really pay attention to the search thing at all, and I’m taking some credit for figuring the O(n2) thing out myself, but damn, not checking for two successive deleted items in the key part of the algorithm I was actually working on. Sloppy!
Fortunately, at work I tend to interleave writing tests with implementing my algorithms, but I have to admit that I’m not sure if I would have thought to check for this case when doing TDD, either.
Sobering thoughts. One should never ever fall to the trap of thinking that a problem is so trivial it doesn’t merit a thorough checking. Because programming is hard:
- If your code deals with arbitrary human text, it’s probably broken. (Have you taken the Turkey test recently?)
- If your code deals with floating point numbers, it’s probably broken.
- If your code deals with concurrency (whether that means database transactions, threading, whatever), it’s probably broken.
- If your code deals with dates, times and time zones, it’s probably broken. (Time zones in particular are hideous.)
- If your code has a user interface with anything other than a fixed size and a fixed set of labels (no i18n), it’s probably broken.
Let me add one to the list: if your code implements an algorithm you that you can’t verify for correctness at a glance, it’s probably broken. Especially if I wrote it.