Fellow Access MVP Daniel Pineault posed this question on his excellent website, DevHut.net, recently:
Is Microsoft Access truly a good choice as a development platform today (in 2021-2022)?
Please read the entire post here:
I've been thinking about Daniel's post for the past 24 hours.
This line in particular has been haunting me, "from a moral and ethical standpoint, as a developer, are you truly looking out for your users’ best interests, or simply your own, by continuing to promote and use Microsoft Access?" (emphasis added)
That's a difficult question for me to answer.
First, Some Context
I have been developing and maintaining Access applications my entire professional programming career.
I did not choose Access.
When I left the Army in 2007, my wife and I moved back to my small hometown in northeast Pennsylvania. I resigned myself to the fact that I would not be able to write software for a living. As luck would have it, though, I landed a software job working for someone who had spent the past ten years developing more than a dozen Access applications.
I did not care what programming language I would be using at my new job; I was just happy to be programming! Over time, though, I came to love and appreciate Access's capabilities.
Fast forward ten years and I had become the proud new owner of Grandjean & Braverman, Inc. Over those ten years, those dozen or so applications had expanded to about three dozen Access programs.
I no longer have the luxury of being indifferent to Access. For better or worse, I will be supporting Access applications for many more years.
So, now you know my biases. Take the rest of my opinions with the appropriate grains of salt.
What are the Alternatives to Access?
There's an obvious two-word followup to Daniel's question about Access as a development environment:
If not Access, what should we be using instead?
To answer this, I need to go back to my early years as a programmer again. Many times during my first ten years working at Grandjean & Braverman, I got fed up with Access and went looking for alternatives.
I wanted a desktop application framework that was:
- Optimized for building CRUD apps
- Had strong print-ready reporting capabilities
- Fit into my clients' development budgets
There were none.
And by alternatives, I mean a rapid application development environment for desktop, line of business applications. The "alternatives," such as they were, fell into roughly three buckets:
- Underpowered low-code data-centric app builders (like FileMaker or OpenOffice Base) with no real programming capability
- Traditional desktop development languages like C++, Java, or .NET (C#/VB) where development costs were 2x - 4x higher than with Access
- Web applications which required constant upgrades to remain secure
However, in the past five years, a fourth bucket has appeared on the scene, combining elements of buckets 1 and 3:
4. Web-based low-code data-centric app builders
This fourth bucket still suffers from the same lack of programmability as option 1, but this simply doesn't seem to matter for many small businesses who would have otherwise been prime candidates for a Microsoft Access solution.
Access: A Victim of Its Own Success
In many ways, Microsoft Access's domination of the desktop database market in the late 1990s and early 2000s may be responsible for its long-term decline.
With no viable competitor–and relatively few untapped customers–Microsoft had no incentive to innovate. And so, Access as a development environment has languished in a sort-of software purgatory for more than a decade.
For Access developers, this was a double-edged sword.
On the one hand, there were no exciting new features to look forward to. But, on the other hand, the darn thing Just Worked™.
Or, at least, it used to.
Where Has All the Stability Gone?
As Daniel rightly points out in his post, recent bug releases from Microsoft have poured cold water on the whole, "It Just Works™" idea.
Microsoft's once-cherished commitment to backward compatibility has been replaced with the Silicon Valley mantra of "move fast and break things." Unfortunately for Access developers, Microsoft is only delivering on the latter part of that promise.
To be fair to the Access team, many (most?) of these bugs have originated with other departments in Microsoft, such as the security team or the VBA team. Of course, that's small comfort to clients whose software suddenly stops working.
What's starting to concern me is that some of these bugs may turn out to be irreconcilable with security updates. For example, is the lock file concept itself fundamentally insecure?
If Microsoft can sort out these reliability issues–a big IF, apparently–Access still stands alone as the premier RAD tool for desktop database development. And while that niche is smaller than it once was, it's still alive and well.
Microsoft to Access: Why Won't You Die?
There's a line in Austin Powers 2 that captures Microsoft's apparent attitude toward Access (watch on Youtube):
For years, Microsoft seems to have invested the absolute bare minimum in resources to keep Access development afloat.
And even then, those meager resource investments go towards developing features that no Access developer has been asking for:
I truly believe that if Microsoft could kill Access off once and for all–while suffering no reputational damage–they would do it in a heartbeat.
But the simple fact is that Microsoft is in the same boat as I am: supporting Microsoft Access applications for many more years.
In closing, let's return to Daniel's original question–"Is Microsoft Access truly a good choice as a development platform today (in 2021-2022)?"
To borrow a line from Microsoft's competitor
UPDATED [2022-07-04]: Added links to my recent article, "Microsoft Access: A Victim of Its Own Success."