Recovering From Code Loss

Access just crashed while you were writing code. When you last saved will determine how long it takes to recover, but it's not a linear relationship.

Recovering From Code Loss

We've all been there.  

You're deep in the programming flow, furiously writing code, held back only by your never-fast-enough-to-keep-up-with-your-brain typing speed, when suddenly...Access crashes.  You immediately swear under your breath at the inconvenience.  And then the panic sets in.  When was the last time you saved your work?

The Winding Road to Recovery

How long it's been since you last saved your work will determine how much time it takes to get back to where you were when Access crashed.  But the correlation between TimeSinceLastSave and TimeToRecover is not a linear one.  For a bunch of interesting reasons, it can take you either more or less time to recover than you spent coding since your last save.

I'm using exact times in my examples below, but the times are really only there to provide a general sense of scale.  Also, I'm using the term "since last save" to also capture incidents where a copy of your program was lost to a hard drive crash or similar disaster.  Basically, you should read, "since last save," as, "since the most recent available copy of your program."  You get the idea.

Four minutes since last save

This is the situation where all of the code is very fresh in your mind.  If you think of your brain as a computer, the code is sitting in processor cache.  Only a tiny amount of code can exist there, but you can access it very quickly.

The time it takes to recover is generally limited only by your typing ability.

Time to recover: One minute

Forty minutes since last save

At this point, most of the code you've written is still pretty fresh in your mind.  To continue on with the computer analogy, there's now too much code in your head for it to all fit in your processor cache.  However, there's room enough for it in your brain's RAM.  It will take you a bit longer to retrieve that code from RAM than from the processor cache, but you should be able to retrieve the code mostly intact.

You will likely forget a function here or a variable there, but those omissions generally make themselves known before long.  You'll probably recover the bulk of the lost code from memory in about fifteen minutes.  You'll spend the rest of the time filling in the blanks.

Time to recover: Forty minutes

Four hours since last save

Now we're getting into your brain's swap file.  Unless you're a savant, you're not holding four hours worth of code in your internal RAM.  Some of that code had to be written out to your brain's hard disk.  Not only that, it's probably fragmented, too.

This time, when you try to recall the code you lost, you will almost certainly leave out important details.  After all, four hours worth of code is a lot to keep straight, especially in the situation where you've been in the programming flow and you've been writing code as fast as you can type.

Unfortunately, there's another complication that makes this situation even worse.  Trying to remember back four hours, your brain can't even be sure it remembers where it left off.

Did you ever fall asleep binge watching a TV series?  The next day, you rewatch the episodes that were on as you were falling asleep.  As you're watching, bits and pieces of the show are familiar, but there are also gaps in your memory from when you were drifting in and out of consciousness the night before.

Losing four hours of code is a similar experience.  One of the biggest difficulties is simply trying to figure out where exactly you left off when Access crashed.  Which functions or classes did you write before the last save?  Which ones did you write after the last save?

More importantly, which bugs did you discover and fix after the last save?  Assuming a bug is fixed when it's actually not could cause your recovery time to go through the roof.

Time to recover: Two days

Four days since last save

I'm not suggesting that you went four straight days locking your computer at night and refusing to ever save (if so, you're an idiot and I can't help you anyway).  Rather, this scenario (and the ones that follow) crop up when either: (A) your current copy of the program was deleted and you had to restore from a backup, or (B) you made some major change to the code that turned out to be a horrible decision and you're restoring a previous copy of the program rather than rip out all the new, bad code.

In either case, everything we discussed in the previous section still applies.  There's no way you'll remember all the code you wrote in the last four days.  And you'll be hard-pressed to recall exactly which code you wrote before and after the cutoff.

Time to recover: Two weeks

Four weeks since last save

With four weeks of lost code, the time you spend determining the exact cutoff between the saved and lost code becomes a rounding error in your recovery timeline.  

We've now reached the point, though, where some things are actually working in your favor.  Having to rewrite four weeks worth of code, you have the opportunity to revisit some early design decisions that you may have regretted making.

Time to recover: Four weeks

Four months since last save

This situation is basically a major rewrite of a key feature of the program.  You won't be trying to reproduce every function and routine you wrote originally.  Rather, you will be implementing the feature anew.  Only this time, you will have have learned from the mistakes you made during your original implementation.

With the benefit of that experience, you'll probably be able to implement your solution in about half the time as it took you the first time through.

Time to recover: Two months

Four years since last save

This is the Netscape example.  It's taking four years of development and throwing it all out the window to start over from scratch.  

The allure of rewriting a working application is the Siren song of the programming world.  It is easy to rationalize such an undertaking.  "Finally, we'll be free from all the technical debt of the existing application!"  "Now that we know what not to do, this new version of the application will be even better!"  

When you hear yourself starting to say these things, tell your colleagues to plug their ears with beeswax and lash you to the mast until you regain your senses.

Time to recover: Never

Image by Free-Photos from Pixabay

All original code samples by Mike Wolfe are licensed under CC BY 4.0