Backward Compatibility: A Go Perspective

If you're not familiar with it, Go is an interesting programming language.  Google released version 1.0 of Go (more easily googleable as "golang") in March 2012.  The language's raison d'etre is that it was designed from the start to take advantage of the multi-threading capabilities of modern processors.

I've never written any Go programs myself.  However, I am a big believer in learning about other languages because many of their features can be incorporated into VBA (like doc tests in Python or throwing errors in .NET).  I find the language intriguing, and for the past few months of been on Jon Calhoun's mailing list.

Today's email from Jon talked about something near and dear to my heart: backward compatibility.  

If you've done any web development, you'll understand the frustration that Jon is addressing.  I spend most of my time as a developer writing desktop applications with Microsoft Access.  About every other year, though, I will write a web application.  I'm always amazed to find that everything I used in my previous web application project is now either broken, obsolete, or insecure.

The same thing happens when I start researching my technology of choice.  I'll find a tutorial about how to accomplish some task.  I search for more information about the topic, and the next tutorial tells me not to do it the way the first tutorial recommended.  It's not done that way anymore.  That approach was so six months ago.  Of course, half the tutorials on the web are for the old approach and the others are for the new approach.  It truly is maddening.

Jon summarizes the problem with a simple question:

"What actually makes code, advice, and tutorials obsolete?"

He then offers four possible answers to the question:

1. A breaking change is introduced to the code.
2. A new concept or approach becomes available.
3. New libraries are released and are "better" than existing libraries.
4. Experience, education, or something else changes our opinions.

I'd like to address each of these as they pertain to Microsoft Access and VBA more generally.

(1) A breaking change is introduced to the code

I started out writing VBA for Access 2000.  I also converted several applications written for Access 2.0 and Access 97.  In all those years, I cannot recall a single backwards-incompatible change in either VBA itself or in the Access object model.  New versions of Access introduced new features to the object model.  But, if it worked in Access 2000, it still works in Access 365.

That's not to say that Access as a development platform has never broken backwards compatibility.  There are a few cases that I can think of:

1. Access Data Projects were discontinued beginning in Access 2013.
2. Access Web Apps were a short-lived experiment from Access 2010 - 2016.
3. dBase table support disappeared weirdly from Access 2010 and 2013.

(2) A new concept or approach becomes available

Unfortunately, new concepts or approaches in Microsoft Access have been historically hard to come by.  In some ways, it feels like Microsoft has been trying to kill this platform since the day they bought FoxPro and its Rushmore technology that powers the Access database engine.

When Microsoft has introduced new concepts or approaches, they've tended to abandon them shortly thereafter.  See Access Data Projects and Web Apps above for two such examples.

My personal approach, which has always served me well, is to stick to core Access functionality and avoid relying on new features that Microsoft does not fully commit to.

(3) New libraries are released and are "better" than existing libraries

Unlike most modern programming languages and frameworks, VBA and Microsoft Access do not have a massive library of open-source libraries.  This makes it more difficult to implement some solutions.  However, once those solutions have been implemented, they are likely to continue working from version to version.

(4) Experience, education, or something else changes our opinions

Outside of the ribbon interface introduced in Office 2007, there have not really been any fundamentally new concepts over Access's lifetime.  Outside of the confines of Access development, there have been a fair number of changes in the broader software development world: distributed version control, test-driven development, decoupled user interface design (MVC/MVVM/etc.), cloud storage, and a steady migration from desktop to web-based applications.

To repurpose a joke from my West Point days, one could say that Access represents 25 years of tradition unhampered by progress.

The Go perspective

Let's bring it back to the original article from Jon Calhoun.  Jon argues that Go  supports backward compatibility much better than most modern languages.

"...why does this problem appear to affect other languages more than Go?...My traditional go to answer here is the Go 1 compatibility promise. TL;DR - As long as you are using a Go 1.xx version of the language, you don't have to worry about the standard library suddenly changing from under your feet and breaking your code. In fact, this rule is so strictly followed that there are several instances of libraries that could really use some changes, but doing so would break the compatibility promise, so changes aren't made."

Interestingly, he credits both the language and the community for this achievement.

"I believe another major factor here is how Go developers treat third party libraries, both as consumers and as creators."

"From the creators perspective - I believe Go libraries tend to do a better job of avoiding breaking changes when compared to libraries in other languages."

"From the consumer perspective - it is common advice in Go communities to avoid using libraries as often as possible."

Sound familiar?

I couldn't help thinking about Microsoft Access and VBA as I read through Jon's article.  I feel like he could have just as easily been talking about our world.  I've often read advice about avoiding .ocx's and ActiveX controls wherever possible.  I ignored this advice early in my career, only to take it more seriously when I had to re-write large portions of an application due to deployment problems with an .ocx I had relied on.

The upshot

So what is the ultimate takeaway?  

When I began this article, I meant it to be another defense of Microsoft's pursuit of backward compatibility above all else.  As I wrote it, though, I realized that I had avoided some major backward compatibility headaches largely through sheer luck.

For instance, I never wrote an Access Data Project or Access Web App.  I think if I had, my effusive praise for Microsoft would rely on a different eff-word to describe my feelings.  

Additionally, much of Access's "commitment to backwards compatibility" may be better described as a simple lack of interest in improving the product in any meaningful way.  That certainly puts a less noble spin on things.

My final thoughts

In the end, the Access stasis is a double-edged sword.  By never changing, Access never breaks.  But without ongoing improvements, Access will continue its slow, inexorable death march to obsolescence.  And that saddens me most of all, because I think Access is an underappreciated rapid application development tool.

The Go gopher was designed by Renee French. (http://reneefrench.blogspot.com/)