Make Your Access App More Resilient with Version Control
Reassembling the pieces of a fragile system is a fool's (horse's?) errand. Turning back the clock is a more reliable fix.
No one sets out to write fragile code.
But over the lifetime of an application, simple code becomes complicated. Side effects and dependencies intertwine as complicated code leads to a complex system. As we apply band-aids, bubble gum, and duct tape to handle changing requirements, the already-complex system becomes fragile.
Like the proverbial Humpty Dumpty, fragile systems don't bruise; they shatter.
Recovering a Shattered System
When working with complex and fragile code, small changes can have wide-ranging, unintended consequences.
It's surprisingly easy to apply a handful of small changes, hopelessly break the system, and then not be able to remember exactly what it was you changed. If you wrote the original software, you likely feel like all the king's men, trying in vain to put Humpty Dumpty back together again.
But if you didn't write the original software...then you feel more like the king's horses, pulverizing what's left of the shell into dust as you lament that even the world's best iron horseshoes are no replacement for opposable thumbs.
Turning Back Time
The best way to recover a shattered software system–or an anthropomorphized ovum–is to turn back time to before the precipitating event.
That's exactly what version control allows us to do: turn back the clock to return to a known working state of our application. More than that, it allows us to see exactly what we changed since we were last in that known working state. This is why an actual text-based version control system is superior to the "version control system" most Access developers use (read: making .accdb
copies):
Getting Started with Version Control
If you've been thinking about trying version control with Access, Adam Waller's msaccess-vcs-addin project is a great place to get started: