Warum Menschen immer noch VBA verwenden

• Da Excel in vielen Organisationen zur Grundlage von Geschäftsprozessen geworden ist, wird VBA faktisch zur Standardwahl, wenn kleine Automatisierungen benötigt werden
• Die Beispielorganisation verfügt über 13 Datenplattformen und mehrere Automatisierungstools, doch die Tools mit breitem Zugriff auf die benötigten Datenquellen reduzieren sich im Wesentlichen auf VBA und PowerShell
• CyberSecurity lehnte die Installation von Hochsprachen wie Python, Ruby, Node und Rust ab; die Alternative Power Platform zeigt Grenzen bei Datenzugriff und Wartung komplexer Algorithmen
• Beispiele früherer Migrationen von Lotus Notes und IBM BPM zeigen, dass IT-getriebene Systeme anfällig für Support-Ende, unvollständige Migrationen und Wartungslücken sein können
• VBA ist alt und hat Schwächen, ist aber in Office enthalten und damit für alle zugänglich; es bietet Kontrolle, mit der SMEs Geschäftslogik und Datenmigrationen selbst überprüfen können

---

Die unmittelbaren Gründe, warum VBA weiterhin gewählt wird

• In einer Umfrage auf /r/vba aus dem Jahr 2021 gab die Mehrheit der VBA-Nutzer an, VBA zu verwenden, weil es keine andere Wahl gebe
• Viele Organisationen betreiben ganze Geschäftsprozesse in Excel, und wenn ein wenig Automatisierung nötig ist, ist VBA oft die erste Wahl
• Hinter der Kritik, man „steuere Teile der Infrastruktur mit Tabellenkalkulationen“, stehen Einschränkungen bei den bereitgestellten Tools, beim Datenzugriff und in der Wartungsstruktur der Organisation

Einschränkungen bei Datenzugriff und Automatisierungstools

• Der Engineering-Bereich der Beispielorganisation kann mehrere Automatisierungsplattformen nutzen
  • On-Prem: PowerShell, Excels VBA / eingeschränktes OfficeJS / OfficeScripts / PowerQuery, PowerBI Desktop, SAP Analysis for Office
  • In der Cloud: PowerApps, Power BI, nicht-premium PowerAutomate
  • Sandbox-Umgebungen: ArcGIS mit ArcPy, MapInfo mit MapBasic, InfoWorks ICM mit Ruby, ArcGIS Online
• Die von der IT verwalteten Datenplattformen reichen von D1 bis D13 und umfassen Geodatenbanken, SAP-Datenbanken, Telemetrieplattformen, SharePoint, Lotus Notes, IBM BPM, Dateisysteme und Hydraulic Model Information
• Die Automatisierungsplattformen, die eine Verbindung zu den benötigten Datenquellen herstellen können, laufen im Wesentlichen auf VBA und PowerShell hinaus
  • Power BI Desktop wurde in der Organisation eingeführt, deckt aber nicht alle Plattformen ab, auf die VBA zugreifen kann
  • Selbst bei gleichem Zugriffsumfang ist Power BI schwer für Prozessautomatisierung zu verwenden; um andere Datasets zu verarbeiten, wird häufig eine CSV erzeugt und in SharePoint gespeichert
  • Auch diese CSV-Erzeugung übernimmt in manchen Fällen VBA
• Einige Verbindungen von VBA zu On-Cloud-Diensten basieren auf direkten Versuchen; SAP BW4HANA und andere Cloud-Dienste gelten ebenfalls als per VBA anbindbar, doch Authentifizierungsanforderungen und Protokolle sind noch nicht gelöst

Grenzen von Hochsprachen und der Power Platform

• Die Organisation wollte für Geschäftsautomatisierung Hochsprachen wie Python, Ruby, Node und Rust nutzen, doch alle Anfragen zur Installation im Team oder im gesamten Geschäftsbereich wurden von CyberSecurity abgelehnt
• Als Begründung hieß es, Endanwendern Zugriff auf Hochsprachen zu gewähren, widerspreche der technischen Strategievision des Unternehmens
• Die als Alternative genannten PowerAutomate und PowerApps haben kaum Zugriff auf die benötigten Daten
• Selbst wenn Datenzugriff möglich ist, reicht die Power Platform für die meisten Prozesse nicht aus
  • Die benötigten Algorithmen sind komplex, sodass PowerAutomate-Lösungen schwer zu warten und selbst für IT-Personal schwer zu verstehen sein können
  • Als Beispiel werden Projektionsalgorithmen genannt
• Am Ende bleiben praktisch PowerShell v3 und VBA übrig
  • PowerShell v3 unterstützt keine Klassensyntax, und die Installation von Modulen ist ebenfalls nicht möglich
  • VBA ist das Ziel, für das Hunderte Stunden in Open-Source-VBA-Bibliotheken investiert wurden, um es nach modernen Maßstäben zu einer vernünftigen Sprache aufzurüsten

VBA als Wartungsgarantie

• In den 2000er-Jahren wurden viele Systeme auf Datenbanken von IBM Lotus Notes aufgebaut
• Nachdem Lotus Notes 2019 von HCL übernommen wurde, geriet die Support-Kontinuität ins Wanken; das offizielle Support-Ende war für Juni 2024 vorgesehen
• Ab 2019 versuchte das Technikteam, mehrere Systeme auf neue Technologien zu migrieren, und die Organisation investierte viel Geld in die Entwicklung eines Systems auf Basis von IBM Business Process Manager, um eine einzelne Lotus-Notes-Datenbank zu ersetzen
• Der Plan war, D11 vollständig mit D10-Daten zu befüllen und anschließend D10 zu archivieren, doch der Stand im Jahr 2023 sah anders aus
  • Noch 8 Monate bis zum offiziellen Support-Ende
  • Das Technikteam kündigte den Supportvertrag für IBM BPM
  • Es ist kein Ersatzsystem für IBM BPM und die Lotus-Notes-Datenbank zu sehen
  • Die IBM-BPM-Lösung wird unzureichend gewartet und funktioniert nicht wie benötigt
  • Eine für den Zweck ungeeignete Lösung wurde mit Gewalt in IBM BPM hineingepresst
  • Es gibt eine REST-API, die für das Technikteam und die SMEs aber nahezu nutzlos ist
    • Einige REST-Aufrufe verwenden als String kodiertes JavaScript
    • Andere Aufrufe erfordern HTML in JSON in XML
    • DB-Tabellen werden nicht über Namen, sondern über GUIDs abgefragt
    • Es gibt keine Dokumentation dazu, welche GUID welcher Tabelle oder welchem Prozess entspricht
  • Die D10-Daten wurden tatsächlich nicht nach D11 migriert, sodass der Geschäftsbereich nicht ein, sondern zwei Systeme nutzt
  • Auch das Datenmodell von D11 unterstützt die D10-Daten nicht richtig
• SMEs sind diejenigen, die die Tools täglich verwenden und über notwendige Systemänderungen entscheiden
• Wenn SMEs VBA verwenden, können sie die Systeme im nötigen Umfang direkt kontrollieren und warten; das wirkt als Wartungsgarantie, die IT-Systeme nicht sicherstellen

Kontrolle und Probleme bei der Zusammenarbeit mit SMEs

• Ein aktuelles Projekt sollte eine neue integrierte IT-Lösung schaffen, die eine geschäftskritische Tabelle ersetzt; bei Erfolg sollte die Bedeutung von D6 auf Klasse C herabgestuft werden
• Die ursprüngliche Spezifikation war einfach
  • NodeJS-Server und MySQL-Datenbank
  • React-UI
  • Administratoren und SMEs erhalten Zugriff auf Codebasis und git
  • IT und SMEs bauen das System gemeinsam
• Das Technikteam stellte andere Anforderungen
  • Administratoren und SMEs erhalten keinen Zugriff auf den Code
  • Das Frontend wird gemäß der „Strategic Vision“ mit Microsoft PowerApps gebaut
  • Das Backend wird gemäß der „Strategic Vision“ mit Microsoft Azure Pipelines gebaut
• Aus Sicht der SMEs schafft diese Forderung mehrere Probleme
  • Das Technikteam versteht die operative Arbeit nicht und kann daher Geschäftslogik und Berechnungen nur schwer nachvollziehen
  • Wenn Entwickler die Geschäftslogik schreiben, entstehen leicht Fehler
  • Das Technikteam lässt maßgeschneiderte Technologieprojekte häufig liegen, wodurch Ressourcen für Wartung und Verbesserungen verschwinden
  • Bei Zusammenarbeit mit SMEs kann zumindest ein Team Ressourcen für die Systemwartung aufrechterhalten
  • SMEs müssen den Ergebnissen vertrauen können; ohne Einblick in den Code ist es jedoch schwer zu prüfen, ob er in allen Edge Cases funktioniert
  • Selbst wenn es Unit Tests gibt, ist ohne Codeeinsicht schwer zu überprüfen, ob diese Tests existieren und regelmäßig ausgeführt werden
  • SMEs verbessern und warten bestehende Legacy-Systeme und verfügen über viel Wissen zu Interaktionen zwischen Systemen
  • Um sicherzustellen, dass alle Daten korrekt in das neue System migriert und dort dargestellt werden, ist Zugriff auf das Backend nötig
• Wenn der Code in VBA bleibt, behalten SMEs und Geschäftsbereich Kontrolle
• Das Technikteam gibt dem Business-Team kaum Kontrolle ab, während SMEs prüfen können, dass die Software modular sauber entwickelt wird und nicht zu einem lose zusammenhängenden Technologieklumpen verkommt

User Experience in einer vertrauten Umgebung

• Die meisten Ingenieure verwenden in ihrer täglichen Arbeit Tabellenkalkulationen
• VBA ist in die Tabellenkalkulation eingebettet und kann daher unbekannte Tools in einer vertrauten Umgebung bereitstellen
• Neue Funktionen in eine vertraute Umgebung einzubauen, kann für Nutzer wirkungsvoller sein, als ihnen ein unbekanntes Tool in einer unbekannten Umgebung zu geben

Fazit: VBAs Schwächen und die pragmatische Wahl

• Es gibt mehrere Gründe, warum Organisationen Tabellenkalkulationen und VBA wählen
  • Wegen Sicherheitsbedenken sind die von der IT bereitgestellten Alternativen schwach
  • Alternative Tools können sich nicht zuverlässig mit den Quellsystemen verbinden und befinden sich meist noch in Arbeit
  • Es gibt Probleme mit IT-Strategien, die bestimmte Use Cases nicht berücksichtigen
  • Aus Sicherheits- und Wartungsbedenken wird die Zusammenarbeit mit SMEs vermieden
  • Nutzer, Administratoren und SMEs werden nicht ausreichend in Ersatzsystemen geschult
  • Nutzer und SMEs wollen ein gewisses Maß an Kontrolle über die Geschäftslogik des Systems
  • Es ist die einzige praktikable Technologie, die in Office enthalten ist und von allen genutzt werden kann
• Das heißt nicht, dass VBA keine Schwächen hätte
• Der Beitrag auf mataroa hat in manchen Punkten recht
• Manchmal ist das Management miserabel, aber viele Menschen in Organisationen versuchen, mit den ihnen gegebenen Werkzeugen das Richtige zu tun

[GN⁺]

Hacker-News-Kommentare

• In Unternehmen gibt es bereits innerhalb von Excel eine Entwicklungsumgebung, für die man keine Genehmigung des Managements, Top-Managements, keine Projektregistrierung, kein Budget und keine Zuweisung eines Projektmanagers braucht, um nicht lagergeführte Software freizugeben.
  Wenn man sogar Netzwerkspeicher und ein Web-Interface will, hängt man einfach SharePoint dran. So entstehen Lösungen aus dieser Endnutzer-Perspektive, und diese Lösungen werden mit VBA gebaut

  • In der dystopischen Umgebung eines Unternehmens sollte man nicht erwarten, einfach Software für das eigene Gerät anfordern oder installieren zu können. Man kann nur nutzen, was schon da ist, und Änderungen sind den Kampf mit der Bürokratie nicht wert.
    Früher gab es eine grauenhafte Reporting-Engine in Word VBA, die Berichtsdefinitionen aus einer Dateifreigabe las, Template-Fragmente zusammenkopierte und dann ausgab. Da die IT den PC eines ausgeschiedenen Mitarbeiters nicht eingesammelt hatte, lief darauf den ganzen Tag .doc, um Engineering-Berichte zu erzeugen — viel schneller und billiger, als die Reporting-Option der CAD/CAM-Software zu kaufen. Dafür hätte man mindestens 18 Monate, Berater und Projektbudget gebraucht.
    Wenn Leute schimpfen, dass mit Excel VBA schreckliche Dinge gebaut werden, liegt die Ursache wahrscheinlich weiter oben im Stack. Ein anderer Grund ist das Prinzip „Wer nur einen Hammer hat, für den sieht alles wie ein Nagel aus“: Wenn das einzige verfügbare Werkzeug VBA ist, sieht alles nach einer VBA-Lösung aus. Inzwischen sind wir ein wenig weiterentwickelte Primaten
  • Ich habe mindestens zweimal erlebt, wie ein Abteilungsleiter etwas brauchte, aber das Entwicklerteam nicht stören konnte oder wollte, also mit „Wie schwer kann das schon sein?“ anfing. Am Ende entstehen dann plötzlich ein paar hundert Zeilen VBA, die genau den eigenen Bedarf lösen.
    Im nächsten Schritt will Jim es auch nutzen, also wird das Skript kopiert, Jane verwendet eine andere VBA-Version und passt es an, und dann kommt noch „das hier auch!“ dazu. Am Ende hat man einen 1500-Zeilen-Flickenteppich und versucht, die Wartung dem Entwicklerteam zu übergeben
  • Ein Freund hat seine ganze Arbeit mit Excel automatisiert. Er sagt, dass er die Arbeit eines Tages in 15 Minuten erledigt und den Rest der Zeit ausruht.
    Die Firmenrechner sind so stark abgeschottet, dass man nichts installieren und keine nicht freigegebenen Websites besuchen kann, aber Excel ist da
  • Visual Basic selbst ist auch eine sehr mächtige Sprache. In Umgebungen wie Excel-Makros lässt sich diese Stärke ziemlich weit ausreizen, und viele Power User in Unternehmen tun genau das.
    Das ist ziemlich ähnlich dazu, das frühere Paradigma des „Emacs-Betriebssystems“ auf einen anderen Kontext anzuwenden
  • VBA ist da und funktioniert. Es ist eine sehr zugängliche und intuitive Sprache zum Coden und Iterieren, und man verschwendet keine Zeit mit dem Installieren externer Abhängigkeiten, Library-Hölle oder Kompilierungsschritten.
    Deshalb ist es nicht überraschend, dass VBA in Unternehmen weiterhin sehr wertvoll ist. Selbst in Umgebungen mit anderen Tools und Sprachen und ausgereiften Build-Prozessen habe ich Produktmanager gesehen, die mit VBA verblüffend komplexe Business-Analysen gebaut haben, und für das Problem in ihrer Hand war es das richtige Werkzeug

• Ich war überrascht, wie oft auch professionelle Entwickler Excel/VBA als Hilfswerkzeug nutzen.
  Als ich vor ein paar Jahren mit einem großen Hedgefonds arbeitete, schickte mir ein Datenanalyst ein selbstgebautes Excel-Modell. An der Erweiterung .xlsm sah ich sofort, dass da VBA-Code drinsteckte. Ich dachte mir: „Mal sehen, was die Makro-Aufnahme-Cowboys da gemacht haben.“ Drinnen war eine Menge VBA, und der Autor war ein Datenanalyst mit Caltech-Abschluss in Informatik, der auch sehr gut Python konnte.
  Das VBA diente dazu, Daten aus Datenbanken zu holen, in Sheets einzufügen, Formeln zu erzeugen und alles hübsch zu formatieren; es gab auch ein paar UserForms. Ich habe ihn aufgezogen mit „VBA? Was nutzt ihr da sonst noch, eine Baumwollentkörnungsmaschine und einen Dampfschaufelbagger?“ Aber entgegen meiner Erwartung lobte er Excel und VBA sehr deutlich.
  Was er sagte, ist mir im Gedächtnis geblieben: „Excel macht es leicht, die Abhängigkeitsstruktur zu verstehen, die in den Berechnungen steckt. Wenn ich das in Python gemacht hätte, würde ich den ganzen Tag Fragen beantworten.“

  • Je mehr Erfahrung man als Entwickler sammelt, desto wichtiger wird es, das richtige Werkzeug für die Aufgabe zu verwenden. Eine faule Lösung ist oft viel besser als ein unverständlicher Ideenklumpen
  • VBA hat durchaus Probleme(https://sancarn.github.io/vba-articles/issues-with-vba.html), ist aber weit davon entfernt, das schlechteste Werkzeug zu sein. Zum Beispiel besser als PowerAutomate.
    Rund um VB6 gibt es eine ziemlich große Community, und https://twinbasic.com/ hat in letzter Zeit viel dazu beigetragen, die VBA- und VB6-Communities zusammenzuführen. Daher könnte es in der Entwickler-Community eine kleine Wiederbelebung geben
  • Das Geschäft, das ich betreibe, hängt stark von Google Sheets ab. Indem wir Werte einspeisen und berechnete Werte wieder auslesen, können wir ziemlich komplexe Business-Logik in Form von Tabellen definieren, die von den Geschäfts- und Finanzverantwortlichen leicht angepasst werden kann. Alle sind mit dieser Lösung sehr zufrieden
  • Excel ist für vieles ein großartiges Interface und hilft Menschen bis zu einem gewissen Grad, Daten zu verstehen. Umgekehrt sind Menschen aber so an dieses Datenmodell gewöhnt, dass sie sich, sobald es etwas komplexer wird, eher selbst die Schuld geben, statt Fragen zu stellen.
    In Schweden gibt es sogar ein 3-GB-Excel/VBA-Rentenprognosemodell mit einer 38-seitigen Bedienungsanleitung. Allerdings würde ich das nicht gerade als Beispiel für eine besonders gute Nutzung von Excel sehen: https://www.pensionsmyndigheten.se/statistik-och-rapporter/p...
  • Ich habe die präoperative Aufnahmeklinik eines großen Universitätskrankenhauses mit Excel betrieben.
    VBA ist mächtig, und Prototyping wie Iteration gehen schnell. Man könnte sogar sagen, dass VB6 der Höhepunkt von CRUD-Apps war

• „Weil es verblüffend ist“
  Ich habe mal gehört, dass es früher im Netzwerk von JP Morgan über 20.000 Access-Datenbanken gab. Datenanalysten in vielen Unternehmen hatten eines Tages keine Lust mehr auf ihre tägliche Arbeit und schauten sich die Schaltfläche „Makro aufzeichnen“ an. Manche fanden das ziemlich praktisch und nutzten es weiter. Einige waren schlauer, sahen sich den vom Makro ausgespuckten Code an und versuchten, mit etwas Lernen daran herumzuändern
  Eine kleine Minderheit lernte sogar Datenstrukturen und Algorithmen, baute Authentifizierungs- und Berechtigungssysteme nach dem Vorbild von Django, entwickelte UserForm-UIs von Grund auf neu und implementierte Markdown, SAX-Parsing, benutzerdefinierte Scrollbars, Logging und sogar Spiele
  Die Antwort ist wahrscheinlich, dass Datenanalysten ihre tägliche Arbeit einfach langweilig fanden

  • Es könnte auch daran liegen, dass die IT-Abteilung aus ihrem Elfenbeinturm zu viele Prozesse vorgibt und die Leute dadurch in die Shadow IT gedrängt werden. Ich habe in großen Unternehmen gesehen, wie Analysten, die durchaus in der Lage wären, ihre selbstgebauten Frankenstein-Konstruktionen auf ein ordentliches Niveau zu heben, mit Aussagen wie „Du musst ein Projekt starten und Tickets, Zeitpläne und Anforderungen erstellen“ ausgebremst werden
    Natürlich ist es ein berechtigtes Anliegen, etwas unterstützen zu müssen, in das sich jeder erst einarbeiten muss. Aber solange das Business Zugang zu Werkzeugen hat, mit denen Probleme gelöst werden können, finden „gelangweilte“ Leute einen Weg. Die Reibung ist einfach zu groß
  • „Makro aufzeichnen“ ist der Kern. Selbst wenn Microsoft auf C#, JavaScript oder Python umsteigen würde, wäre es möglich, solange es diese Schaltfläche gibt
  • Das ist dieselbe Erfahrung wie bei vielen Leuten, die aus dem Finanzbereich in Data Engineering oder Systemimplementierung wechseln
    Solange es einfacher ist, in Excel etwas halbwegs Komplexes zu bauen und auf einem Netzwerk-Share abzulegen, als über die IT eine IDE installieren zu lassen, etwas zu entwickeln und nach den Sicherheitsprozessen auszurollen, wird das so schnell nicht verschwinden. Nicht jedes Problem braucht ein Jira-Projekt und eine übermäßig komplexe Lösung
    Allerdings bin ich völlig dagegen, große Dinge in VBA zu bauen. Ein kleines Skript, das je nach Änderungen in ein paar Zellen einen Cube in einem System abfragt und mit Tabellendaten aus einem anderen System zusammenführt, ist in Ordnung, aber ab einem gewissen Punkt muss man woanders hin
    Für die meisten Projekte bevorzuge ich sehr klar einen Alteryx+Tableau/PowerBI-Stack, unter der Annahme, dass Serverlizenzen vorhanden sind und Automatisierung möglich ist
  • Ehrlich gesagt habe ich etwas Ähnliches gemacht, es dann nach C# migriert und bin heute einfach Softwareentwickler

• Ich musste eine einfache CRUD-Oberfläche für Analysten bauen
  Das erste Problem war, dass die Analysten alle CRUD-Schritte innerhalb von Excel erledigen wollten. Da Excel die eigentliche Oberfläche war, brauchten wir etwas, das innerhalb von Excel laufen konnte
  Die IT-Abteilung erlaubte keinen Zugriff auf die Kommandozeile und lehnte auch die Installation nicht genehmigter Entwicklungstools ab. Bis eine Genehmigung durch war, konnten Monate vergehen. Die Datenbankadministratoren waren nicht begeistert davon, einer bestehenden Oracle-DB eine neue Datenbank hinzuzufügen, und die IT-Abteilung wollte auch keine Datenbank selbst betreiben
  Sogar für ein neues Add-in in Excel musste man den IT-Verantwortlichen hinterherlaufen. Wenn man Glück hatte, tauchte das Add-in eines Tages einfach auf, aber man wusste nie, ob das einen Tag, eine Woche oder einen Monat dauern würde
  Deshalb war die einzige realistische Alternative VBA, und am Ende gelang es uns, einen provisorischen Fix für die Analysten bereitzustellen, den sie alle zwei Wochen nutzten

• Als ich bei einem Nachrichtendienst arbeitete, musste ich eine App für Leute bauen, die in Afghanistan stationiert waren. Die einzigen Computer, die sie nutzen konnten, waren gesperrte Windows XP-Rechner, und es gab keine Möglichkeit, etwas Neues zu installieren
  Weil alles an das bereits freigegebene und installierte Office gebunden war, war selbst ich als Linux-Nutzer an Office gebunden. Nur mit reinem VBA habe ich einige ziemlich wilde Frankenstein-Konstruktionen gebaut und dafür gute Bewertungen bekommen

  • Aus der Perspektive von jemandem, der im Nahen Osten stationiert war: gleiche Erfahrung. Auf vollständig air-gapped XP-Rechnern habe ich so viel wie möglich mit VBA automatisiert
  • Ähnliche, aber nicht ganz dieselbe Situation: Ich habe mich mit HTML-Dateien beholfen, die JavaScript-Code in script-Tags enthielten. Ich frage mich, ob auf diesen air-gapped Maschinen selbst das Starten von IE blockiert war oder ob VBA einfach bequemer war als JavaScript

• Seien wir ehrlich: IT ist die moderne Bürokratieabteilung, zu 95 % mit selbst geschaffenen Problemen beschäftigt und vielleicht zu 5 % serviceorientiert. Für Außenstehende sind die Prozesse intransparent und meist nicht hilfreich
  Ich musste wirklich lachen, als ich so etwas in einer IBM-BPM-Erklärung gelesen habe, denn es fasst einen großen Teil des Problems gut zusammen
  „IBM BPM hat zwar eine REST API, aber diese REST API ist für technische Teams und KMU nahezu unbrauchbar. Manche REST-Aufrufe verwenden als String codiertes JavaScript, andere Aufrufe verlangen HTML in JSON in XML. Datenbanktabellen werden nicht nach Namen, sondern per GUID abgefragt. Es gibt keine Dokumentation dazu, welche GUID mit welcher Tabelle bzw. welchem Prozess verknüpft ist“
  Vieles ist so absurd komplex geworden, dass niemand außerhalb der IT es anfassen will und manchmal nicht einmal jemand innerhalb der IT. Seit AJAX geht ungefähr die Hälfte des Entwicklungsaufwands in das Design von Frontend-Code und Backend-Services, was mit dem Problem der Endbenutzer-Automatisierung in Wahrheit kaum etwas zu tun hat. Danach wurde es nur noch schlimmer, und heutige UIs sehen zwar modern aus, sind für Nutzer aber fast so feindselig wie der Tech-Stack, mit dem sie gebaut wurden
  In Excel ist die UI einfach „da“, es gibt einen Makrorekorder als Codegenerator, und die IT-Abteilung diskutiert nicht erst meine Berechtigungen aus oder sagt mir, sie habe weder Zeit noch Budget, um mein Geschäftsproblem zu lösen. Deshalb ist VBA der Umgehungsweg, mit dem Nutzer die IT-Abteilung umgehen. Es ist nicht perfekt, aber besser als die anderen Alternativen

• VBA ist die ultimative agile Programmiersprache. Die Unternehmens-IT, also die Bürokratieabteilung, ist an Scrum, Squads und Ähnliches gebunden, während Leute in anderen Abteilungen ihre Arbeit mit Excel/VBA erledigen
  Nichts hat sich geändert. So etwas gab es schon im letzten Jahrhundert, und es wurde Automatisierungsinseln genannt. Damals galt das in meinem Umfeld als gute Strategie: Man ließ die Abteilungen erst einmal damit spielen und integrierte es später, wenn Potenzial sichtbar wurde

• Wenn man lange genug sucht, findet man in jeder Abteilung schlechte Beispiele. Gibt es unter den Dingen, die von der IT verwaltet werden, auch welche, die beinahe jenseits von Gut und Böse sind? Natürlich. Aber das ist keine gute Rechtfertigung dafür, Shadow IT zu schaffen
  Wenn ein paar Analysten zusammenkommen und sich ihr eigenes kleines VBA-Tool zusammenhacken, stört mich das überhaupt nicht. Dieser Geist ist lobenswert, und das Ergebnis könnte sogar dazu führen, dass ich meinen Arbeitsalltag besser verstehe
  Was mich stört, ist der Moment, in dem diese Analysten erwarten, dass sich meine Systemarchitektur irgendwie ihrem privaten Projekt anpasst. Wenn man nach Dokumentation fragt, gibt es keine, eine Architekturübersicht gibt es auch nicht, und wenn man um Repository-Zugriff auf das Monster bittet, heißt es: „Was ist ein Repository?“
  Dann fragen sie, warum ihre Tabellenkalkulation keine Daten in meine Verarbeitungspipeline einspeisen darf, und finden, ich solle Controller passend zu irgendwelchen REST-Schnipseln schreiben, die sie aus einem halb angesehenen YouTube-Video gelernt haben. In Meetings kommen dann Fragen wie: „Was bedeutet es, dass Authentifizierung nötig ist? Warum macht die IT alles immer so kompliziert?“
  Ob VBA, Low-Code oder sonst etwas: Es ist gut, wenn Leute Werkzeuge bauen. Ich mache dasselbe, nur nenne ich es Shell-Skripte und lege sie in ein Git-Repository. Aber so wie ich mein CLI-Tool nicht einfach auf einen Produktionsserver loslassen würde, würde ich dort auch nichts ohne wenigstens einen einzigen Code-Review laufen lassen

• Einer meiner ersten regulären Jobs im Software Engineering bestand darin, auf dem Trading Floor einer Bank direkt neben Devisenhändlern zu sitzen und zu arbeiten
  Eingestellt hat mich der Leiter des Marktrisikomanagements, dessen Aufgabe es war sicherzustellen, dass die Bank an einem Tag nicht zu viel Geld verliert. Er stellte mich ein, weil er nicht darauf vertraute, dass die offiziell zuständige IT-Abteilung den Code zur Implementierung seiner Algorithmen korrekt schreiben würde. Sie hatten zum Beispiel schon Fehler gemacht, weil sie nicht verstanden, dass bei der Operatorpräzedenz Multiplikation vor Addition kommt
  Für die Marktrisikoberechnung mussten alle Geschäfte als Eingabe erfasst werden, und da das Anfang der 2000er war, installierte ich Apache und Perl CGI auf einem PC unter dem Schreibtisch und baute eine kleine App, mit der die Händler Geschäfte eingeben und Positionen verfolgen konnten. Die Händler begannen diese Lösung der offiziellen IT-Lösung vorzuziehen, weil sie einfacher zu benutzen war und Positionen besser darstellte
  In vielen Unternehmensumgebungen ist die Fähigkeit, Wege an der IT vorbei zu finden, eine wichtige Funktion. Um auf Excel zurückzukommen: Die Händler nutzten Excel für Berechnungen und Simulationen, und wir versuchten Werkzeuge bereitzustellen, die sich in Excel einklinkten, um das zu nutzen, was sie ohnehin schon taten

• Im Artikel steht ein Satz, dass dies eine ausdrückliche politische Entscheidung des Unternehmens sei
  „Endbenutzern Zugang zu einer Programmiersprache auf hohem Niveau zu erlauben, widerspricht der Vision der Technologiestrategie des Unternehmens“

• Das ist die Antwort. Weil VBA die einzige Programmiersprache ist, deren Installation ein Unternehmen nicht ablehnen kann
  Die Wunderwelt des „Enterprise“. Ich bin immer wieder erstaunt, wenn Leute das hervorholen, als wäre es ein Vorteil oder eine Entschuldigung

• Bis vor Kurzem gab es schlicht keine gute Alternative. Die Zukunft liegt im neuen Modell für Office-Add-Ins: https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...
  Man kann über TypeScript sagen, was man will, aber es ist zumindest besser als VBA. Ein großes Problem ist allerdings, dass man damit im Gegensatz zu VBA nicht direkt in Excel programmieren kann. Manchmal will man kein ausgewachsenes Add-In-Projekt starten, das auf Wiederverwendung ausgelegt ist, sondern nur ein Skript, das man jetzt sofort einmal grob ausführt, um etwas zu beheben. Dabei bin ich auf Script Lab gestoßen (https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...); vielleicht hilft das.

  • „Im Gegensatz zu VBA kann man nicht direkt in Excel programmieren“ ist fast schon ein Ausschlusskriterium
    Dazu kommt die offensichtliche Frage: Können Nutzer ohne entsprechende Berechtigungen das Add-In ohne Eingreifen der IT-Abteilung installieren? Kann es in die Tabellenkalkulation eingebettet werden? Wenn Ersteres „nein“ ist, ist das wirklich fatal, und auch wenn Letzteres „nein“ ist, schadet das der Akzeptanz. Der Vorteil von Makros und VBA ist, dass sie – abgesehen von Sicherheitseinstellungen – in jeder Excel-Instanz ohne zusätzliche Installation sofort laufen
  • Den Hinweis auf Script Lab am Ende des Kommentars hatte ich übersehen. Wenn du Microsoft Script Lab meinst, dann kann genau das das: https://www.microsoft.com/en-us/garage/profiles/script-lab/
    Das andere Problem ist, dass das Teilen eines Add-Ins mit Endnutzern nicht trivial ist. Man muss es im Marketplace oder in SharePoint veröffentlichen, und für Sideloading braucht man einen SMB-Server und GPO. Es gibt allerdings eine Option, die fast nirgends gut erwähnt wird: Wenn man es in das Dokument einbettet, kann es beim ersten Öffnen nach Bestätigung durch den Nutzer installiert werden
  • Wenn es nur darum geht, eine schicke UI für Dateneingabe oder Visualisierung zu zeigen, ist es gut, aber OfficeJS kann leider nicht einmal die Hälfte dessen, was VBA kann. Wenn das Add-In-System nur FFI hätte, wäre ich für immer umgestiegen
    Ein weiteres großes Problem ist, dass man für OfficeJS einen Webserver hosten können muss. Die meisten Endnutzer haben normalerweise keinen solchen Zugriff

• VB(A) ist ähnlich wie Python. Nicht schön, aber es erledigt die Arbeit. Wenn du es schön findest, fehlt dir vermutlich die Erfahrung, um viele bessere Alternativen zu kennen
  Ein Werkzeug mit einem guten Ökosystem, also mit Tools, Bibliotheken und Integrationen, das es einem ermöglicht, reale Arbeit zu erledigen, ist nützlich. Als System zur Entwicklung von Desktop-Apps war Visual Basic zusammen mit MS Access und dessen DB-Vorteilen in vielen Situationen sehr nützlich. Wenn etwas darüber hinausging, war in der Regel auch Geld da, um zu einer „echten“ Lösung zu skalieren
  Es steht außer Zweifel, dass mit VBA-basierten Systemen enorme Summen verdient wurden. Soweit ich das aus meiner eher externen Perspektive auf Finanzentwicklung erlebt habe, war die größte Excel/VBA-Neuschreibung die eines Unternehmens, das um 2008 herum mit Credit Default Swaps sehr viel Geld verdiente. Vor der Neuschreibung dauerte es fünf Minuten, bis die Arbeitsmappe geöffnet war, aber VBA übernahm einen Großteil der schweren Arbeit. Die Leute mit dem entsprechenden Wissen verdienten für das Unternehmen und für sich selbst über Boni sehr viel Geld
  Die Lehre daraus ist, dass es wichtiger ist, ob ein Werkzeug für Menschen zugänglich ist, die nicht speziell für dessen Nutzung ausgebildet wurden, als ob es ideal ist. Aus demselben Grund wurde Python außerhalb des Client-Webbrowsers zur Nummer eins. Das heißt nicht, dass es das Beste ist, sondern dass es die Arbeit erledigt und zugänglich ist

  • Man kann durchaus argumentieren, dass Python eine schöne Sprache ist: eine vollwertige Sprache mit Klassen und Unterstützung für Funktionen erster Klasse, die zugleich relativ einfach und zugänglich ist
    Das ist aber nicht der einzige Grund für seine Popularität. Es verfügt über die robustesten Data-Science-Tools, was einen überwältigenden Effekt hatte, und es gibt auch brauchbare Web-Frameworks wie Django und Flask. Ein weiterer Grund für den Popularitätsschub ist, dass es an vielen Universitäten Java als „erste Lernsprache“ ersetzt hat. Auf VBA trifft das nicht zu
  • Python ist schön, und ich finde die Verwendung von Whitespace besser als Strategien zur Blockkennzeichnung wie geschweifte Klammern, begin/end oder if/else
    Erfahrung bedeutet auch zu wissen, dass bei der Frage, ob etwas schön ist oder nicht, ein subjektives Element dabei ist. Dass VBA unter „harten“ Bedingungen entstanden ist, erklärt einige seiner Merkwürdigkeiten zumindest teilweise
  • Python ist vielleicht nicht Scheme, aber unter Programmiersprachen ist es definitiv ziemlich schön, und in vielen Fällen gibt es keine deutlich bessere Alternative. Maßstab dafür sind rund 25 Jahre Programmiererfahrung mit mehreren Dutzend Sprachen

• VBA ist eine brauchbare Sprache mit Unterstützung für objektorientierte Programmierung. Vererbung gibt es nicht, aber Komposition ist möglich. Sie erlaubt tiefen Zugriff auf Excel und dessen Steuerung und ist ausgereift und stabil, weil Microsoft daran kaum noch größere Änderungen vornimmt
  Dass „echte Programmierer“ VBA nicht mögen, liegt meist daran, dass es viel amateurhaften Spaghetti-VBA-Code gibt, der von Leuten aus dem Business geschrieben wurde, und Programmierer gelegentlich gebeten werden, ihn zu debuggen

  • Dagegen lässt sich einwenden, dass VBA eine schreckliche Sprache ist, sobald man den Zugriff auf und die Steuerung von Excel, Word usw. ausklammert
    Sie steckt voller merkwürdiger Eigenschaften, etwa dass Steuerzeichen im Code lokalisiert werden.[1][2] Wenn Code auch auf nicht englischen Installationen laufen soll, muss man Platzhalter wie Application.International(xlDecimalSeparator) verwenden und die an solche Funktionen übergebenen Strings dynamisch zusammenbauen, was die Lesbarkeit massiv verschlechtert. Wenn Code deshalb kaputtgeht, sind die Fehlermeldungen unglaublich wenig hilfreich, und wenn ein Entwickler nicht weiß, dass dies ein potenzielles VBA-Problem ist, ist eine Reproduktion praktisch unmöglich. Zur Reproduktion muss man die Sprache der Benutzeroberfläche auf eine Sprache umstellen, die man womöglich gar nicht kennt
    Zumindest in Word funktioniert ungefähr die Hälfte der nützlichsten Funktionen nicht mehr, wenn man sie am letzten Absatz einer Tabellenzelle verwendet, etwa beim Einfügen eines Absatzes nach dem aktuellen Absatz, sodass jede Menge Spaghetti-artige Workarounds nötig sind
    Wenn man Textstrings mit mehreren Formatierungen senden und empfangen möchte, ähnlich wie beim Zugriff auf die innerHtml-Eigenschaft eines DOM-Elements, ist das nicht einfach, außer man nutzt hackige skriptbasierte Auswahl- und Kopieren/Einfügen-Methoden
    Jemand anders hatte es in einem anderen Thread mit Bash verglichen, und ich stimme tatsächlich zu. Man sollte in keiner dieser Sprachen etwas Komplexes schreiben
    [1] https://stackoverflow.com/questions/20652409/using-vba-to-de...
    [2] https://stackoverflow.com/questions/29832281/vba-range-funct...
  • Ich habe enorm viel Zeit in den Aufbau einer VBA-Bibliothek (https://github.com/sancarn/stdVBA) investiert und mag VBA, aber es gibt reale Probleme, die die Sprache stark einschränken (https://sancarn.github.io/vba-articles/issues-with-vba.html)
    Allerdings stimmt auch, dass ein großer Teil der Abneigung gegen VBA vom Zustand vieler VBA-Projekte herrührt (https://sancarn.github.io/vba-articles/why-is-vba-most-dread...)
  • Ich finde, es ist fair, eine Umgebung kritisch zu sehen, die Fehlkonstruktionen wie On Error Resume Next enthält

• Wenn man an Excel und Tabellenkalkulation insgesamt denkt, wird außerhalb dieser Welt oft nicht verstanden, wie gut die Sprache von Tabellenkalkulationen reaktive funktionale Programmierung umsetzt. Genau daran arbeiten React/Angular seit mehr als 10 Releases mit mäßigem Erfolg
  Viele verstehen auch nicht, warum Tabellenkalkulationen für Endnutzer so bequem sind, und liefern deshalb unterlegene UIs, die die Dinge in der Praxis sogar schwieriger machen
  Manchmal muss man einen Schritt zurücktreten und verstehen, dass die Leute früher manches auch ohne grafische UI richtig gemacht haben. Schon in der Anfangszeit lief das Business, und die meiste Zeit brauchten Unternehmen vor allem eine tabellarische Ansicht und die Möglichkeit, darauf reaktive Funktionsberechnungen auszuführen. Frag einen Freund, der in einem kleinen oder mittleren Unternehmen arbeitet, dann wird er das bestätigen

  • Ein erheblicher Teil des Aufwands in der Webentwicklung fließt in die Präsentation. Wenn man nur die Daten braucht, ist es schwer, etwas Besseres als eine Tabellenkalkulation zu finden
  • Excel kann man als die beste jemals erfundene IDE für Endnutzer betrachten