Why do people still use VBA?

Original Article ↗ Hacker News Discussion ↗

VBA persists because Excel and the rest of Microsoft Office are the only programmable tools many employees are actually allowed to use in tightly locked‑down corporate environments. Commenters describe how non‑developer “power users” automate entire jobs, prototype line‑of‑business tools, and glue systems together with macros, despite VBA’s age, quirks, and security risks. The broader theme is a tension between restrictive IT policies and the need for fast, end‑user‑driven automation, which current “modern” alternatives like Office add‑ins, cloud‑hosted Python, or web apps often fail to match in accessibility and integration.

Embedded, Ubiquitous Tooling

  • VBA is bundled with Office (especially Excel/Access/Word/Outlook) and requires no extra installs, approvals, or infrastructure.
  • The IDE, debugger, and GUI form builder are built-in and stable; macros can be recorded and then edited.
  • That “right there in Excel/Word” experience is contrasted with add‑ins, web apps, or separate IDEs that need IT involvement.

Corporate Lockdown and Shadow IT

  • Many environments are heavily locked down: no software installs, no command line, no modern runtimes, sometimes even USB blocked.
  • In such places, VBA (and sometimes PowerShell) is literally the only programmable environment users can access.
  • This drives “shadow IT”: business users build Excel/Access/VBA systems because going through official IT is slow, expensive, or dismissive.

Productivity, Prototyping, and “Automated My Job”

  • Numerous anecdotes of people automating days of manual work down to minutes using VBA.
  • Often starts as a quick macro and grows into mission‑critical tools (thousands of lines) used for reporting, trading, manufacturing, logistics, etc.
  • Some see these systems as dangerous kludges; others see them as valuable living prototypes and proof of business value that IT could later industrialize.

Language & IDE: Strengths and Weaknesses

  • Praised: simple, approachable syntax; tight integration with Office object models; good debugger; forms; COM/Win32 access; fast enough.
  • Criticized: archaic, quirky semantics; poor modularity; no modern features (generics, lambdas); “On Error Resume Next”; localization landmines; hard to version‑control and test.

Alternatives and Successors

  • PowerShell, Python, JS, Office Scripts, OfficeJS add‑ins, VSTO, RPA tools, Jupyter, etc. are discussed.
  • Barriers: need for installs, servers, licenses, cloud execution (data‑leak concerns), limited Office integration, no in‑document editor, or restricted deployment.
  • Newer options (Python in Excel, Office Scripts, OfficeJS) are viewed as promising but currently too limited, cloud‑tied, or hard to distribute.

Security Concerns

  • Macros have long been a major malware vector; some orgs now disable them entirely.
  • Others cannot, because too many workflows depend on them; security mitigations are partial and uneven.

Organizational Dynamics

  • Recurrent theme: IT/security optimized for control and risk avoidance vs. business users optimized for getting work done.
  • VBA persists because it sits at the intersection of “already installed,” “powerful enough,” and “not blocked,” enabling end‑user computing when formal IT processes can’t or won’t.