Fast, Easy, Cheap: Pick One

Just some other blog about computers and programming

CRA System Grinds to a Halt

Thanks to Slashdot I found out about this total snafu at the almighty CRA (Canadian Revenue Agency). Apparently their E-filing systems are temporarily offline because of database corruption.
It turns out that they’ve detected records where somehow the “Social Insurance Number” and “Date of Birth” fields became swapped. My question of course, as a computer engineer, is how the hell is this even possible? Was their system built by morons? Completely likely.

Anyone who’s learned even the slightest bit about programming should have a concept of data types. Well, it’s pretty clear even to a layman that a date and a social insurance number look nothing alike! A date is typically something like 1983/05/26 whereas a SIN is something like 032 324 356 (no, that’s not my real SIN, so don’t try to use it to steal my identity!)

Any half-decently designed system, and especially a half-decently designed system that manages the collection of our income tax, should have some sort of data validation. Yes CRA programmers, I’m looking at you, you should probably go buy a book on the subject since it looks like you need it…

This data should have been validated on at least 4 different levels:

  • Different data types used to store it in the database, it should be impossible to insert a date field in to a SIN column and vice versa.
  • Different data classes on the application level for representing dates and SINs, it should not be possible to convert from one class to the other.
  • Validation of the numbers using a validating algorithm. Check to make sure the dates are in a valid range, and validate the SIN using the Luhn Algorithm. That’s what it’s there for!
  • Input validation on the user end, so that users can’t possibly enter one where they mean the other. Even these 4 basic steps would have gone a long way to prevent this kind of error. Who wants to take bets on how many of them are in use in the CRA system?