Manifesto

A Manifesto for Community Takeover on the VBA Ecosystem

How Microsoft Violated the Prime Directive with Access

Microsoft Access has acquired a considerable amount of bad reputation, among IT people. Much of it is not directly the fault of that software, but of a bold decision of its designers, back in 1992: Microsoft wanted to put it in the hands of non-IT people.

This was a worthy goal, except that the tool soon became too technical for non-expert users, and it did not contain elementary safeties and did not enforce good practices.

Ms Access has been far too powerful for the average level of knowledge of its users, and the result has been a Far West place: where only the toughest could survive for a long time, and those who did survive formed an unruly groups with little regard to method or security. Ms Access has fuelled a resentment and even hatred among IT departments, against shadow IT projects.

That's what happens when a software company does things half-way: remember Star Trek's Prime Directive: giving a powerful technology to a less-advanced culture without taking the responsibility to ensure that it is applied correctly, will result in strife and social misery.

The result was cultural contamination, a cultural disaster in which a population is equipped with tools it cannot master, and has turned turning those tools as weapons against those who brought them in the first place.

As a result of this, Microsoft could abandon neither sides to its fate: it had to continue to support Access, and even give some occasional facelifts to it. On the other hand, it never tried to make it unleash its true potential; and it never ported it to MacOs. There has been too much frowning and angry opposition on the other side.

Instead, Access was left to vegetate as a semi-illegal weapon for the underworld, and Microsoft never cared to enrich it with the professional extensions it deserved.

The Unwanted Effects of Prometheus' Gift

Let us go a little more in the detail of how the office world was unprepared for Ms Access, back in 1992, and is still unprepared in 2018.

Uncharted Territory

Users of Access, and particularly VBA were mostly left on their own, in uncharted territory.

Did it occur to anyone that relational algebra is a very advanced mathematical theory? How do you hope that novices would get a immediate grasp of normalization, identifiers, keys, foreign keys, etc., without proper schooling? This is way out in the stratosphere for your common office worker!

VBA and its Archaic Constructs

Indeed, VBA is an old language, frustratingly obsolete compared to Python.

Building a query in Access?

More importantly, VBA lacks a decent string interpolation mechanism. How important is it? Forcing programmers to write code as this is sadistic:

a = 5
message = "hello"
strSQL = "SELECT * FROM mytable WHERE foo = " & 5 & " AND bar = '" & "hello" % "'"

Go try to explain that to a novice programmer? Good luck. You have put a monumental barrier to learning, just there.

Compare that to Javascript:

var a = 5
var message = 'hello'
var strSQL = "SELECT * from mytable WHERE foo = ${a} and bar = '${message}'"

How to represent the results of a query?

The results of a query, in abstract terms, are a "table" i.e. a list of rows. Now try to represent that in VBA.

What about the Byzantine differences between Arrays and Collections? Arrays are static structures, but their elements are modifiable. Collections are dynamic structures, but their elements are modifiable. Of course the explanation lies ultimately in history, but to beginning programmers it will be nonsense. And nonsense it is, because we know that the difference is arbitrary and dictated purely by a question of implementation. But your novice programmer will have to learn it as some natural law of data structures. And passing arbitrary human constructs as the Will of the Gods is blasphemy.

It is a pity that the designers of VBA did not care to expand it a little, to give it a decent list type. Did we really have live forever with this painfully clumsy Array type, as well as this Collection type that went some of the way, but not quite?

Perhaps it is because Microsoft were fully aware of Access' potentiel that they voluntarily sacrificed it in order to develop other tools or platform, notably VB.net and languages like C#, which were meant for traditional development (even though VBA and Access would not have threatened them).

They left Access (and to a large degree Excel) booby-trapped left and right.

Even if it was done out of prudence or wariness, "sadism" seems appropriate, considering that Access (and VBA) were supposed to be accessible to non-professional programmers, who could not know better: why giving them a "toy" to people with which they were going to hurt themselves and hurt others?

I cannot help picturing a few professional software engineers, watching an inexpert programmer trying to get a SELECT query to work with ADODB, with the same smug sneer of the drug pusher who watches an eager teenager getting his first fix: "good luck, kid".

Efforts at Education

Back in the early 2000s, there was considerable effort to make VBA accessible, but let's face it, those who wrote tutorials were faced with a horrible task.

Of those who did a magnificent work in that field over the years, lets quote:

• C Pearson, with its impressive list of how-tos.
• Ron de Bruin, who also provides solutions for MacOS

These were used for Excel, but many were applicable to Access as well.

One of the best books (to my knowledge) ever written on the subject of Access was: Fixing Access Annoyances: Tame the Database Monster, by Phil Mitchell & Evan Callahan... and it dates back to 2006.

The title say everything about a benevolent tool that had turned into a Frankenstein Monster or the gift of a Modern Prometheus.

Their level of difficulty is inordinately high, because they aim to fix implementation issues that Microsoft never bothered to fix.

Could Microsoft Have Done Better with Access?

Yes. Access was not at fault as a tool, no more than than the fire introduced by Prometheus was at fault; it was the methodology that accompanied its introduction.

It would have been indeed possible to put Access in the hands of a "less-advanced" culture (office staff inexperts in information technology), but that would have required a special care in accompanying the process:

1. Microsoft Access should have belonged, really, in the professional segment as an entry-level Rapid Application Development environment, and novices should have been introduced with it with care, as part of an education movement for office workers.

2. The awful "annoyances" should be fixed, so that novice programmers could focus on learning their trade, instead of painfully finding workarounds and failing most of the time.

3. The tool should have embedded pointers "do this and not that", as well as safeties.

This is 2018. It is abnormal that the scripting language of two popular products, Excel and Access, has been left to rot, and with messy ecosystems (particularly Excel on MacOS).

And no, introducing a JavaScript API to Excel will not make the problem go away; you do not fix the engine of an old car by piggy-backing another engine on top of it. Fix the the engine, period.

Instead of being the tool of desperados, VBA could have been a worthy scripting language of the family of Php, Javascript or Python, capisce?

VBA might never have been an excellent language, but it could have been worthy and respectable, nevertheless. And one that would have paved the road for new professional programmers, like BASIC had in the past.

Instead, it has left quite a a trail of devastation in the corporate world.

The way forward: Community takes over from Microsoft

Access ranks as a missed opportunity, a metaphorical jewel thrown away by designers who did not realize its value, to hapless novices who did realize it, but were denied its potential and thus were sent to their doom. For those who did not have a map of the way out, it has been a deadly trap.

Is all that a reason to turn our backs to the past? Or more precisely: Is it still possible to repair the damage caused by this violation of the Prime Directive?

Again, there is nothing wrong with introducing the masses to programming; or with a language with obsolete constructs. For the latter, a language is a reflection of time it was created, and time passes by quickly, in the computing world.

Those obsolete constructs, complications, or lack of safeties are not wrong in themselves, as long as one tries to fix them.

But for Microsoft, as well as the a good part of the Open Source community, to stay obstinately silent about these violations and do nothing to fix them, while thousands of programmers are still wallowing in the mud because of some false Cult of Programming (a result of the violation of the Prime Directive) has been a cover-up. For the most part, it has been ignorance, avoidance of the truth or protection of status quo. Now we should make it a public scandal, so that we start fixing the mess.

Whether we like it or not, Ms Access (as well as Ms Excel) are still around us, they are the most used apps used around (sorry LibreOffice) and whether we like it or not, VBA is the language to pilot them.

The marketing or development teams at Microsoft, out of the best reasons, will keep throwing the dust under the carpet and they will presumably not do anything about it. The Open Source community has to do it in their place.

The Open Sommunity should fix as many VBA problems as possible, once and for all.

There is recent movement in that direction as shown by Tim Hall's list of tools. But much more is needed. vba-db is a contribution to that effort.

Perhaps (maybe, as sometimes happens in those cases) Microsoft engineers might get piqued and start moving on their own to fix the environmental disaster that the company has unwittingly caused twenty-five years ago. But this may not be happening soon.

So until that day, let us expect nothing from them, with the notable exception of graceful hosting on the Github platform. Let us turn Ms Access into the benevolent tool for the masses it was supposed to be.

Deus industriam iuvat[^1].

[^1]: God will help those who put in some work to help themselves.