Sympathy for the devil?

Mike Wolfe -

"Real" Programmers Don't Use Access

If you spend any amount of time on software forums, you will find lots of examples of people asking questions about Microsoft Access and others responding with condescension instead of help.  The exchange often goes something like this:

OP: Hey, how do you do this thing in Access?
Answer: Step 1. Use a real programming language like [.NET|Java|Python|Go|C++|Ruby|Perl|FORTRAN|Assembly].
Step 2. Never ever use Access ever again.  I mean it. NEVER.

OK, so maybe that's a slight dramatization.  But I remember questioning my worth as a developer the first few times I read those kinds of comments.

If you're anything like me--or any programmer, ever--you've likely struggled with Impostor Syndrome.  That feeling that you're not really smart enough or talented enough to be writing code.  That if you're not careful, one day somebody will figure you out.  Comments like the above don't help.

But with age comes experience.  And with experience comes wisdom.  And I've learned to ignore those kinds of comments (well, mostly).  The fact is that Microsoft Access is just a tool.  And in the hands of a skilled craftsman, it's a tool that will do fine work.

It's OK to be a Tool

The important thing is to understand Access's place in the software ecosystem.  Access does a few things extremely well.

  1. It integrates seamlessly with Excel and Word.  This is no small thing in the business world.
  2. It allows for rapid development of CRUD applications (Create/Read/Update/Delete).  In the business world, that's a lot of applications.
  3. Setting up the development environment is...not even really a thing.  You just open Microsoft Access.  
  4. It comes with everything you need to build a full-fledged desktop application: form designer, report designer, persistent storage, and a (more than capable) programming language.

It's just as important to understand what Access is not.

  1. Access is not for web applications.  Period.  Full stop.  
  2. It is not suited for storing sensitive data in multi-user applications as it lacks fine-grained security options. (Though it's fine as a front-end interface to a more capable back-end, like SQL Server.)
  3. It should not be used for multi-developer projects.  (One way to make such a project work would be to split the full project into multiple front-end applications.)
  4. It's a poor choice for creating a prepackaged application for wide distribution.  

Where Access Fits

After over 13 years developing dozens of Access applications, I have found that Access is at its best in the following scenario:

  1. Deployed within an Active Directory network domain environment;
  2. Over a wired LAN (a brief network disruption often requires closing and reopening the Access front-end);
  3. Supporting up to 15 concurrent users;
  4. For data-heavy applications that require saving and retrieving structured data;
  5. In an environment with ever-changing requirements; and
  6. Using SQL Server (Express or higher) for back-end data storage.

Keep in mind, this is my ideal scenario.  For example, Access can obviously work in an environment where the requirements rarely change.  But if the requirements won't be changing, Access's comparative advantage as a rapid application development tool is reduced.  In other words, Access will work in scenarios where only a few of the above criteria are met, but in those cases there are likely other languages or frameworks better suited to the task.

The Bottom Line

Microsoft Access is not the devil.  And you are not a bad person or a wannabe programmer just because you use it.  

You can use it to write great software.  You can use it to write crappy software.  I'm here to help you write more of the former and less of the latter.