The pedagogy of data corruption

When I was 8 years old, I received my first computer – a Commodore 64 purchased at a yard sale. Not long after, a friend of mine supplied me with a box of pirated software on 5 1/4 inch diskettes. Included in the batch was, to my delight, a port of the early Nintendo game Bubble Bobble. Not owning any sort of console machine and having been enamored with the quarter-eating arcade edition of this very game at the local bowling alley, my younger brother and I teamed up on many afternoons to try to race through the one hundred mini levels to the end.


Except we never got to the end, but not for lack of skill. The disk was corrupt. Somewhere around level 70, glitchy levels began to show up. Sometimes the glitch was just a funny artifact on the screen, but before long, it would be misplaced blocks in the level itself. When the faulty positions made it impossible to clear the screen of an enemy, then you were done for. You were permanently stuck in the level until you ran out of time.

We kept a log and figured out which levels were especially glitchy and found that by carefully timing a series of warp “umbrella” power ups (ignoring some, and getting others at the right moment), we were able to skip ahead to somewhere in the upper eighties. But sooner or later the inevitable would happen. An enemy would escape the boundary of the game and find himself hovering in the score dashboard where weapons could not reach him.

It seems funny to admit, but the truth is, to this day, I have yet to ever make it to the end of Bubble Bobble. I never owned a copy that was fully intact. But that maybe turned out to be a good thing.

On reflection, this experience played a significant early part in the wiring of the brain of a little boy. The mistakes on the screen weren’t random. They were not akin to someone sabotaging a chess game by bumping the table as they passed by. The chaos followed careful rules. Positions were off by one, or the color was off by one, or an entire array was shifted in one direction. The underlying data structure of maps was revealed on the screen to anyone paying attention. The draconian piece of code that continuously checked for the condition of all “enemies equals zero” to trigger an advancement was now no longer just an entertaining goal, but a cold, hard rule. Winning became not the crossing of a sparkly finish line, but the satisfying of an IF statement. When one realized how incredibly EASY it was to get stuck in a level when a single block was out of place, it became much more apparent how much care had been put into the design of what was there to begin with. The many hours of work behind the scenes was laid bare – not by a teacher, not by the source code, but by an error. In particular, an error that didn’t prevent execution. The fragile medium of the floppy disk and the early days when memory checksums and buffer overflows were allowed to slide – these enabled the impossible – a serendipitous pulling back of the curtain.

We are told that when we fall down, we need to get back up on our feet and keep going. Dusting yourself off is part of a healthy childhood. Helicopter parents try to keep everything so padded that this isn’t allowed to happen, or when it does, kids are rescued too quickly. We’ve learned to treat our machines the same way. (Or perhaps we treat our kids like machines?) Every exception is caught, every error handled, and anything unusual brings the whole train to a halt. We believe software to be rock solid today, but what it mostly is is all or nothing. Back in ancient times when corruption was not accounted for, things could go rogue and gallop off on the road less traveled, making all the difference – especially for those watching.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>