Reverence for Backwards Compatibility

A feature that was heavily used by a very small percentage of power users has been maintained over the course of five subsequent upgrades (and counting). Now that is showing reverence to backwards compatibility.

Reverence for Backwards Compatibility

From the time I started my career as a professional software developer over 13 years ago, most of my development has been in Microsoft Access.  Of course, Access is not the right tool for every job.  

Over the years, I have written applications in other languages and frameworks.  This includes projects written in Python, VB.Net, and C#.  I've used frameworks like Django, DevExpress, ASP.NET, and web2py, among others.  My point is that I have worked in other environments.  And there are things I absolutely love about each of them.  

Unfortunately, since I only work in those other environments occasionally, it always takes me some time to get back up to speed.  And the thing that drives me absolutely nuts is that most of those other environments have no respect for backwards compatibility (web2py is a notable exception).

The web frameworks are by far the worst offenders.  The web application development world changes at a mind-bogglingly breakneck pace.  When I go back to add requested features to a project that is a couple of years old, I spend anywhere from several hours to several days dealing with all of the breaking changes that have been introduced.

Microsoft's roots are in the business world.  Nowhere is that clearer than in their steadfast commitment to backwards compatibility in the Office suite of programs.  Microsoft Access is no exception.

I'm maintaining many programs that were originally written for Access 2.0.  For the most part, the upgrade path from Access 2.0 to 97 to 2000 to 2003 to 2007 has been very smooth.  The upgrade path from 2007 to 2019 is hardly worth mentioning because almost* everything just works (*for some odd reason, Access dropped .dbf support in 2013 but immediately brought it back in 2016).

Why did I say "reverence" for backwards compatibility and not some similar word, such as "commitment"?  It's because commitment does not do justice to the lengths that Microsoft goes to maintain backwards compatibility.  Let me illustrate with an example.  

In Access 2003, the last version of Access before the ribbon was introduced, all of the commands were available from the menu.  This meant that these commands could be accessed using the [Alt] key on the keyboard and a series of letters.  For example, to align a group of selected controls to the right, one could press [Alt] + [O], [A], [R] (Format -> Align -> Right).  To resize all selected controls to match the widest in the selection, one could press [Alt] + [O], [S], [W] (Format -> Resize -> Widest).  With the introduction of the ribbon, those same commands are still available via the keyboard, but they are accessed using a different set of key presses.

So, how do I still know the keyboard commands from an application that was superseded by a newer version over 13 years ago?  Because the old keyboard command sequences from Access 2003 still work in Access 2019.  Let me repeat that.  A feature that was heavily used by a very small percentage of power users has been maintained over the course of five subsequent upgrades (and counting).  Now that is showing reverence to backwards compatibility.

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