Mengapa Orang Masih Menggunakan VBA

 (sancarn.github.io)
3 poin oleh GN⁺ 2023-11-16 | 1 komentar | Bagikan ke WhatsApp
  • Di banyak organisasi, Excel menjadi fondasi proses kerja, sehingga saat dibutuhkan otomasi kecil, VBA pada praktiknya menjadi pilihan default
  • Organisasi dalam contoh memiliki 13 platform data dan berbagai alat otomasi, tetapi alat yang dapat mengakses sumber data yang dibutuhkan secara luas pada akhirnya menyempit menjadi VBA dan PowerShell
  • CyberSecurity menolak pemasangan bahasa tingkat tinggi seperti Python, Ruby, Node, dan Rust, sementara alternatif Power Platform menunjukkan keterbatasan dalam akses data dan pemeliharaan algoritme yang kompleks
  • Contoh sebelumnya dengan Lotus Notes dan IBM BPM menunjukkan bahwa sistem yang digerakkan IT bisa rentan terhadap akhir dukungan, migrasi yang tidak tuntas, dan kekosongan pemeliharaan
  • VBA memang tua dan punya kelemahan, tetapi karena termasuk dalam Office dan dapat diakses siapa saja, VBA memberi kendali agar SME dapat langsung memverifikasi logika bisnis dan migrasi data

Alasan langsung mengapa VBA terus dipilih

  • Dalam survei /r/vba tahun 2021, mayoritas pengguna VBA menjawab bahwa mereka memakai VBA karena tidak ada pilihan lain
  • Banyak organisasi menjalankan seluruh proses kerja dengan Excel, dan ketika hanya butuh sedikit otomasi, VBA sering menjadi opsi pertama
  • Di balik kritik seperti “mengendalikan sebagian infrastruktur dengan spreadsheet” ada keterbatasan pada alat yang disediakan organisasi, akses data, dan struktur pemeliharaan

Keterbatasan akses data dan alat otomasi

  • Divisi engineering di organisasi contoh dapat memakai beberapa platform otomasi
    • OnPrem: PowerShell, VBA di Excel / OfficeJS terbatas / OfficeScripts / PowerQuery, PowerBI Desktop, SAP Analysis for Office
    • OnCloud: PowerApps, Power BI, PowerAutomate non-premium
    • Lingkungan sandbox: ArcGIS dengan ArcPy, MapInfo dengan MapBasic, InfoWorks ICM dengan Ruby, ArcGIS Online
  • Platform data yang dikelola IT diberi nama D1 hingga D13, mencakup DB geospasial, SAP DB, platform telemetri, SharePoint, Lotus Notes, IBM BPM, file system, Hydraulic Model Information, dan lain-lain
  • Platform otomasi yang bisa terhubung ke sumber data yang dibutuhkan pada akhirnya hanya VBA dan PowerShell
    • Power BI Desktop sudah diterapkan di organisasi, tetapi tidak mencakup semua platform yang dapat diakses VBA
    • Bahkan jika cakupan aksesnya sama, Power BI sulit dipakai untuk otomasi proses, dan untuk menangani dataset lain biasanya dipakai cara membuat CSV lalu menyimpannya di SharePoint
    • Pembuatan CSV itu pun kadang ditangani oleh VBA
  • Sebagian koneksi VBA ke layanan OnCloud didasarkan pada percobaan langsung, dan meskipun SAP BW4HANA serta layanan cloud lain tampaknya bisa dihubungkan lewat VBA, kebutuhan autentikasi dan protokolnya masih belum terpecahkan

Keterbatasan bahasa tingkat tinggi dan Power Platform

  • Organisasi ingin memakai bahasa tingkat tinggi seperti Python, Ruby, Node, dan Rust untuk otomasi kerja, tetapi semua permintaan pemasangan di tim atau di seluruh bisnis ditolak oleh CyberSecurity
  • Alasan penolakan adalah bahwa memberi pengguna akhir akses ke bahasa pemrograman tingkat tinggi bertentangan dengan visi strategi teknologi perusahaan
  • Sebagai alternatif, PowerAutomate dan PowerApps disebut-sebut, tetapi hampir tidak bisa mengakses data yang dibutuhkan
  • Bahkan jika akses data memungkinkan, Power Platform tetap kurang memadai untuk menjalankan sebagian besar proses
    • Algoritme yang dibutuhkan terlalu kompleks sehingga solusi PowerAutomate sulit dipelihara dan bahkan bisa sulit dipahami oleh staf IT
    • Sebagai contoh disebutkan projection algorithms
  • Pada akhirnya, alat yang secara praktis tersisa adalah PowerShell v3 dan VBA
    • PowerShell v3 tidak mendukung sintaks kelas dan juga tidak memungkinkan pemasangan modul
    • VBA adalah bahasa yang sampai perlu didukung dengan ratusan jam kerja untuk membuat open source VBA libraries agar lebih masuk akal menurut standar modern

VBA sebagai jaminan pemeliharaan

  • Pada tahun 2000-an, banyak sistem dibangun di atas database IBM Lotus Notes
  • Setelah Lotus Notes diakuisisi HCL pada 2019, keberlanjutan dukungannya menjadi goyah, dan penghentian dukungan resmi dijadwalkan pada Juni 2024
  • Sejak 2019, tim teknis berusaha memindahkan berbagai sistem ke teknologi baru, dan organisasi mengeluarkan biaya besar untuk mengembangkan sistem berbasis IBM Business Process Manager guna menggantikan satu database Lotus Notes
  • Rencananya adalah mengisi D11 dengan seluruh data D10, lalu mengarsipkan D10, tetapi keadaan pada 2023 berbeda
    • Tersisa 8 bulan hingga akhir dukungan resmi
    • Tim teknis menghapus kontrak dukungan IBM BPM
    • Tidak ada sistem pengganti yang terlihat baik untuk IBM BPM maupun database Lotus Notes
    • Solusi IBM BPM kurang dipelihara dan tidak berjalan sesuai kebutuhan
    • Solusi yang tidak cocok untuk tujuannya dipaksa dimasukkan ke IBM BPM
    • Ada REST API, tetapi hampir tidak berguna bagi tim teknis maupun SME
      • Beberapa panggilan REST memakai JavaScript yang dienkode sebagai string
      • Panggilan lain mengharuskan HTML dimasukkan ke dalam JSON di dalam XML
      • Tabel DB di-query dengan GUID, bukan nama
      • Tidak ada dokumentasi tentang GUID mana yang sesuai dengan tabel atau proses tertentu
    • Data D10 pada praktiknya tidak dipindahkan ke D11, sehingga bisnis memakai 2 sistem, bukan 1
    • Model data D11 juga tidak mendukung data D10 dengan baik
  • SME adalah pihak yang memakai alat setiap hari dan menentukan kebutuhan perubahan sistem
  • Jika SME memakai VBA, mereka bisa langsung mengendalikan dan memelihara sistem sejauh yang diperlukan, dan ini berfungsi sebagai jaminan pemeliharaan yang tidak dijamin oleh sistem IT

Kendali dan masalah kolaborasi dengan SME

  • Proyek terbaru adalah membuat sistem IT terintegrasi baru untuk menggantikan spreadsheet inti bisnis, dan jika berhasil, tingkat pentingnya D6 akan turun menjadi kelas C
  • Spesifikasi awalnya sederhana
    • Server NodeJS dan database MySQL
    • UI React
    • Hak akses ke codebase dan git untuk administrator serta SME
    • IT dan SME berkolaborasi membangun sistem
  • Tim teknis kemudian mengajukan tuntutan lain
    • Administrator dan SME tidak boleh mengakses kode
    • Frontend dibangun dengan Microsoft PowerApps agar sesuai dengan “Strategic Vision”
    • Backend dibangun dengan Microsoft Azure Pipelines agar sesuai dengan “Strategic Vision”
  • Dari sudut pandang SME, tuntutan ini menimbulkan banyak masalah
    • Tim teknis tidak memahami pekerjaan operasional sehari-hari, sehingga sulit memahami logika bisnis dan perhitungan
    • Jika pengembang menulis logika bisnis, kesalahan lebih mudah terjadi
    • Tim teknis sering meninggalkan proyek teknologi kustom sehingga sumber daya untuk pemeliharaan dan perbaikan menghilang
    • Jika berkolaborasi dengan SME, setidaknya satu tim bisa mempertahankan sumber daya untuk memelihara sistem
    • SME harus bisa mempercayai hasilnya, tetapi jika kode tidak terlihat, sulit memverifikasi apakah sistem bekerja di semua edge case
    • Sekalipun ada unit test, jika kode tidak terlihat, sulit memastikan bahwa test itu benar-benar ada dan sering dijalankan
    • SME punya banyak pengetahuan tentang perbaikan dan pemeliharaan sistem legacy yang ada serta interaksi antar sistem
    • Untuk memastikan semua data dipindahkan dan direpresentasikan dengan benar di sistem baru, akses ke backend diperlukan
  • Jika kode tetap berada di VBA, SME dan bisnis mempertahankan kendali
  • Tim teknis hampir tidak pernah menyerahkan kendali kepada tim bisnis, dan SME dapat memastikan perangkat lunak benar-benar dikembangkan secara modular alih-alih menjadi tumpukan teknologi yang saling terhubung longgar

Pengalaman pengguna dalam lingkungan yang familier

  • Sebagian besar engineer memakai spreadsheet dalam pekerjaan sehari-hari
  • VBA tertanam di dalam spreadsheet, sehingga dapat menghadirkan alat yang tidak familier di dalam lingkungan yang familier
  • Bagi pengguna, menambahkan fungsi baru ke dalam lingkungan yang familier bisa lebih kuat daripada memberi alat yang tidak familier di lingkungan yang juga tidak familier

Kesimpulan: kelemahan VBA dan pilihan yang realistis

  • Ada berbagai alasan mengapa organisasi memilih spreadsheet dan VBA
    • Alternatif yang disediakan IT lemah karena kekhawatiran keamanan
    • Alat alternatif tidak dapat terhubung dengan baik ke sistem sumber, dan biasanya masih dalam proses
    • Ada masalah strategi IT yang tidak mencerminkan sebagian use case
    • Karena kekhawatiran keamanan dan pemeliharaan, mereka tidak mau berkolaborasi dengan SME
    • Pengguna, administrator, dan SME tidak mendapat pelatihan yang memadai untuk sistem pengganti
    • Pengguna dan SME menginginkan tingkat kendali tertentu atas logika bisnis sistem
    • Ini adalah satu-satunya teknologi yang benar-benar layak dipakai karena sudah termasuk dalam Office dan tersedia bagi semua orang
  • Bukan berarti VBA tidak punya kelemahan
  • Tulisan mataroa ada benarnya dalam beberapa bagian
  • Kadang pengelolaannya memang buruk, tetapi banyak orang di organisasi tetap berusaha melakukan hal yang benar dengan alat yang tersedia

Bacaan terkait

1 komentar

 
GN⁺ 2023-11-16
Komentar Hacker News

  • Di perusahaan, sudah ada lingkungan pengembangan di dalam Excel yang tidak perlu melewati manajemen, manajemen atas, pendaftaran proyek, anggaran, penunjukan manajer proyek, dan sebagainya untuk mendapatkan persetujuan software non-inventaris
    Kalau ingin penyimpanan data jaringan dan antarmuka web, cukup sambungkan SharePoint. Solusi muncul dari arah pengguna akhir seperti ini, dan solusi itu dibuat dengan VBA

    • Dalam lingkungan distopis bernama perusahaan, jangan berharap bisa meminta atau memasang software di perangkat sendiri. Yang bisa dipakai hanya yang sudah ada, dan untuk mengubahnya harus melawan birokrasi, jadi tidak sepadan
      Dulu ada mesin laporan mengerikan yang dibuat dengan Word VBA; ia membaca definisi laporan dari file share, memotong dan menempelkan potongan template, lalu mencetaknya. Karena IT tidak menarik PC milik orang yang sudah keluar, PC itu dipakai seharian untuk menjalankan .doc dan membuat laporan engineering; jauh lebih cepat dan murah daripada membeli opsi pelaporan dari software CAD/CAM. Opsi itu kemungkinan butuh minimal 18 bulan, konsultan, dan menghabiskan anggaran proyek
      Saat orang mencela hal-hal mengerikan yang dilakukan dengan Excel VBA, penyebabnya kemungkinan besar ada di lapisan stack yang lebih atas. Penyebab lain adalah “palu monyet”: kalau monyet diberi palu, apa pun akan dipukul; begitu juga jika satu-satunya alat yang dimiliki adalah VBA, semuanya terlihat seperti solusi VBA. Sekarang kita sudah menjadi primata yang sedikit lebih berevolusi
    • Setidaknya dua kali saya melihat adegan ketika manajer departemen membutuhkan sesuatu, tetapi tidak bisa atau tidak mau merepotkan tim developer, lalu memulai dengan “memangnya sesulit apa sih”. Tak lama kemudian muncul VBA beberapa ratus baris yang menyelesaikan kebutuhannya
      Pada tahap berikutnya, Jim juga ingin menjalankannya sehingga skrip disalin, Jane memakai versi VBA lain lalu memodifikasinya, dan sekarang muncul permintaan “yang ini juga!” sehingga makin diperluas. Akhirnya menjadi tambal sulam 1500 baris, lalu mereka mencoba menyerahkan pemeliharaannya ke tim developer
    • Seorang teman mengotomatiskan seluruh pekerjaannya dengan Excel. Katanya pekerjaan sehari selesai dalam 15 menit, sisanya bersantai
      Komputer perusahaan sangat terkunci sehingga tidak bisa memasang apa pun, dan tidak bisa mengunjungi situs yang tidak masuk whitelist, tetapi Excel tersedia
    • Visual Basic sendiri juga bahasa yang sangat kuat. Dalam lingkungan seperti macro Excel, kekuatan itu bisa dimanfaatkan cukup besar, dan banyak power user di perusahaan memang memakainya seperti itu
      Ini cukup mirip dengan menerapkan paradigma “sistem operasi Emacs” lama ke konteks yang berbeda
    • VBA ada di sana, dan berfungsi. Bahasanya sangat mudah diakses dan intuitif untuk coding serta iterasi, dan kita tidak perlu membuang waktu memasang dependensi eksternal, menghadapi neraka library, atau menjalani tahap kompilasi
      Jadi tidak mengherankan kalau VBA masih sangat bernilai di perusahaan. Bahkan di lingkungan yang punya alat dan bahasa lain serta prosedur build yang matang, saya pernah melihat product manager melakukan analisis bisnis yang sangat kompleks dengan VBA sampai membuat orang ternganga, dan untuk masalah yang mereka hadapi, itulah alat yang tepat

  • Saya terkejut melihat developer profesional pun banyak memakai Excel/VBA sebagai alat bantu
    Beberapa tahun lalu saat bekerja dengan sebuah hedge fund besar, seorang data analyst mengirim model Excel buatannya sendiri. Melihat ekstensi .xlsm, saya menduga ada kode VBA di dalamnya. Saya pikir, “mari lihat apa yang dilakukan para koboi perekam macro ini,” tetapi ternyata di dalamnya ada banyak VBA, dan penulisnya adalah data analyst lulusan ilmu komputer Caltech yang sangat mahir Python
    VBA dipakai untuk mengambil data dari database lalu memasukkannya ke sheet, membuat formula, memberi format agar enak dilihat, dan ada juga beberapa UserForm. Saya menggodanya, “VBA? Di sana pakai apa lagi? Mesin pemisah biji kapas dan sekop uap?” Namun, di luar dugaan, ia sangat memuji Excel dan VBA, dan itu mengejutkan saya
    Saya ingat ucapannya. “Excel membuat struktur dependensi yang tersirat oleh perhitungan mudah dipahami. Kalau ini saya buat dengan Python, saya akan menghabiskan seharian menjawab pertanyaan”

    • Semakin berpengalaman sebagai developer, semakin penting memakai alat yang sesuai dengan pekerjaan. Solusi malas kadang jauh lebih baik daripada tumpukan ide yang mustahil dipahami
    • VBA memang punya masalah (https://sancarn.github.io/vba-articles/issues-with-vba.html), tetapi jauh dari alat terburuk. Misalnya, lebih baik daripada PowerAutomate
      VB6 punya komunitas yang cukup besar, dan https://twinbasic.com/ belakangan banyak membantu menyatukan komunitas VBA dan VB6. Jadi mungkin ada sedikit kebangkitan di komunitas developer
    • Bisnis yang saya jalankan sangat bergantung pada Google Sheets. Dengan cara menyuntikkan nilai dan membaca nilai hasil perhitungan, kami bisa mendefinisikan logika bisnis yang cukup kompleks dalam bentuk spreadsheet, dan orang bisnis maupun keuangan dapat menyesuaikannya dengan mudah. Semua orang sangat puas dengan solusi ini
    • Excel adalah antarmuka yang bagus untuk banyak hal, dan sampai batas tertentu membantu orang memahami data. Sebaliknya, orang sudah terbiasa dengan model data itu, sehingga ketika menjadi sedikit rumit, mereka cenderung menyalahkan diri sendiri tanpa bertanya
      Di Swedia bahkan ada model prediksi pensiun Excel/VBA 3GB dengan panduan pengguna 38 halaman. Namun, sulit menyebutnya contoh pemanfaatan Excel yang sangat baik: https://www.pensionsmyndigheten.se/statistik-och-rapporter/p...
    • Sebuah klinik rawat inap pra-operasi di rumah sakit universitas besar dijalankan dengan Excel
      VBA kuat, cepat untuk prototyping dan iterasi. Bahkan bisa dibilang VB6 adalah puncak aplikasi CRUD

  • “Karena mengejutkan”
    Dulu saya pernah mendengar bahwa di jaringan JP Morgan ada lebih dari 20 ribu database Access. Para analis data di berbagai perusahaan suatu hari bosan dengan pekerjaan harian mereka, lalu melirik tombol “rekam makro”. Ada yang merasa itu cukup praktis dan terus memakainya. Ada juga yang bertindak lebih cerdas: melihat kode yang dihasilkan makro, belajar sedikit, lalu mencoba mengubahnya
    Segelintir orang bahkan mempelajari struktur data dan algoritma, lalu membuat sistem autentikasi dan otorisasi yang meniru Django, membangun ulang UI UserForm dari nol, serta mengimplementasikan Markdown, parsing SAX, scrollbar kustom, logging, bahkan gim
    Jawabannya mungkin karena analis data bosan dengan pekerjaan harian mereka

    • Bisa juga karena departemen IT menurunkan terlalu banyak prosedur dari menara gading, sehingga orang-orang terdorong ke shadow IT. Di perusahaan besar, saya pernah melihat analis yang sebenarnya mampu membawa Frankenstein buatan mereka ke level yang layak, tetapi terhalang oleh hal-hal seperti “harus memulai proyek dan membuat tiket, jadwal, serta persyaratan”
      Tentu saja, kekhawatiran bahwa sesuatu yang harus didukung dan dipelajari semua orang itu valid. Namun selama bisnis memiliki akses ke alat untuk menyelesaikan masalah, orang-orang yang “bosan” akan menemukan caranya. Friksinya terlalu besar
    • “Rekam makro” adalah intinya. Sekalipun Microsoft menggantinya dengan C#, JavaScript, Python, dan sebagainya, asal tombol itu ada, hal tersebut tetap mungkin
    • Ini pengalaman yang sama seperti banyak orang yang memulai di bidang keuangan lalu berpindah ke rekayasa data atau implementasi sistem
      Karena membangun sesuatu yang cukup kompleks di dalam Excel lalu menaruhnya di network share lebih mudah daripada melewati IT untuk memasang IDE, membuat sesuatu, melewati prosedur keamanan, lalu menerapkannya, tampaknya ini tidak akan berakhir dalam waktu dekat. Tidak semua masalah membutuhkan proyek Jira dan solusi yang terlalu rumit
      Namun saya sepenuhnya menentang membuat sesuatu yang besar dengan VBA. Skrip kecil yang, berdasarkan perubahan nilai beberapa sel, melakukan query cube di satu sistem lalu menggabungkannya dengan data tabel dari sistem lain masih baik-baik saja, tetapi pada titik tertentu harus pindah ke tempat lain
      Untuk sebagian besar proyek, dengan asumsi ada lisensi server sehingga bisa diotomasi, saya sangat menyukai stack Alteryx+Tableau/PowerBI
    • Sejujurnya saya pernah melakukan hal serupa lalu pindah ke C#, dan sekarang saya hanya menjadi pengembang perangkat lunak

  • Saya harus membuat antarmuka CRUD sederhana untuk para analis
    Masalah pertama adalah para analis ingin menangani semua langkah CRUD di dalam Excel. Karena Excel adalah antarmuka sebenarnya, kami membutuhkan sesuatu yang bisa dijalankan di dalam Excel
    Departemen IT tidak mengizinkan akses command line, dan juga menolak pemasangan alat pengembangan yang belum disetujui. Mendapat persetujuan bisa memakan waktu berbulan-bulan. Para administrator database tidak senang menambahkan DB baru ke Oracle DB yang sudah ada, dan departemen IT juga tidak suka mengoperasikan DB sendiri
    Bahkan sekadar memasang add-in baru di Excel pun harus memohon kepada staf IT. Kalau beruntung, suatu hari add-in itu tiba-tiba muncul, tetapi entah apakah itu akan memakan waktu sehari, seminggu, atau sebulan
    Jadi satu-satunya alternatif yang realistis adalah VBA, dan pada akhirnya kami berhasil meluncurkan solusi tambal-sulam sementara yang dipakai analis setiap dua minggu sekali

  • Saat bekerja di sebuah badan intelijen, saya harus membuat aplikasi untuk orang-orang yang ditempatkan di Afganistan. Komputer yang bisa mereka gunakan hanyalah Windows XP yang terkunci, dan tidak ada cara untuk memasang apa pun yang baru
    Karena sudah terikat pada Office yang telah diverifikasi dan terpasang, saya yang biasanya memakai Linux pun ikut terikat pada Office. Dengan VBA murni saja, saya membuat cukup banyak Frankenstein dan mendapat penilaian baik

    • Dari sudut pandang pernah ditempatkan di Timur Tengah, pengalaman saya juga sama. Di komputer XP yang sepenuhnya terisolasi dari jaringan, saya mengotomatiskan sebanyak mungkin hal dengan VBA
    • Dalam situasi yang mirip tetapi tidak sama, saya bertahan dengan file HTML yang berisi kode JavaScript di tag script. Saya penasaran apakah mesinnya terisolasi dari jaringan tetapi IE diblokir, atau apakah VBA memang lebih nyaman daripada JavaScript

  • Harus diakui, IT adalah departemen birokrasi modern; 95% waktunya sibuk dengan masalah yang mereka ciptakan sendiri, dan orientasi layanannya mungkin sekitar 5%. Bagi orang luar, prosesnya tidak transparan dan biasanya tidak membantu
    Saya benar-benar tertawa saat membaca bagian seperti ini dalam penjelasan IBM BPM, karena itu merangkum sebagian besar masalah dengan baik
    “IBM BPM memang punya REST API, tetapi REST API ini hampir tidak berguna bagi tim teknis dan UKM. Sebagian panggilan REST memakai JavaScript yang dienkode sebagai string, sementara panggilan lain meminta HTML di dalam JSON di dalam XML. Tabel database dicari berdasarkan GUID, bukan nama. Tidak ada dokumentasi tentang GUID mana yang terkait dengan tabel/proses mana”
    Banyak hal menjadi sangat rumit hingga tidak ada orang di luar IT yang mau menanganinya, dan kadang bahkan orang IT sendiri pun tidak. Sejak AJAX, separuh upaya pengembangan mulai terserap untuk merancang kode frontend dan layanan backend, padahal ini sebenarnya hampir tidak ada hubungannya dengan masalah otomasi pengguna akhir. Setelah itu keadaan makin buruk, dan UI masa kini memang terlihat modern, tetapi sama tidak ramahnya bagi pengguna seperti tech stack yang dipakai untuk membuatnya
    Di Excel, UI-nya sudah “ada di sana”, ada juga generator kode bernama macro recorder, dan departemen IT tidak akan mempermasalahkan izin saya atau mengatakan mereka tidak punya waktu dan anggaran untuk membantu masalah bisnis saya. Jadi VBA adalah jalan pintas bagi pengguna untuk melewati departemen IT. Tidak sempurna, tetapi lebih baik daripada alternatif lain

    • VBA adalah bahasa pemrograman agile paling ekstrem. IT perusahaan, alias departemen birokrasi, terikat pada hal-hal seperti Scrum dan Squad, sementara orang-orang di departemen lain menyelesaikan pekerjaan dengan Excel/VBA
      Tidak ada yang berubah. Ini juga terjadi pada abad lalu dan disebut pulau otomasi. Di sekitar saya saat itu, ini dianggap strategi yang baik: biarkan departemen bereksperimen dulu, lalu integrasikan jika terlihat menjanjikan
    • Kalau mencari cukup lama, Anda bisa menemukan contoh buruk di departemen mana pun. Apakah ada hal-hal yang dikelola IT yang mendekati level tidak waras? Tentu saja ada. Namun itu bukan alasan yang baik untuk membuat shadow IT
      Saya sama sekali tidak terganggu jika beberapa analis berkumpul dan meretas alat VBA kecil mereka sendiri. Semangat seperti itu patut dipuji, dan hasilnya mungkin membuat saya lebih memahami pekerjaan sehari-hari saya
      Yang mengganggu adalah ketika para analis itu suatu saat berharap arsitektur sistem saya entah bagaimana harus mengakomodasi proyek pribadi mereka. Saat diminta dokumentasi, tidak ada; gambaran arsitektur juga tidak ada; saat diminta akses ke repositori si monster itu, jawabannya menjadi “repositori itu apa?”
      Mereka bertanya mengapa spreadsheet mereka tidak boleh menyuntikkan data ke pipeline pemrosesan saya, dan menganggap saya harus menulis controller agar sesuai dengan potongan REST yang mereka pelajari dari menonton setengah video YouTube. Dalam rapat muncul pertanyaan, “Apa maksudnya perlu autentikasi? Kenapa IT selalu membuat semuanya rumit?”
      Baik VBA, low-code, atau apa pun, orang membuat alat itu bagus. Saya juga melakukan hal yang sama, hanya saja saya menyebutnya shell script dan menaruhnya di repositori Git. Namun sebagaimana saya tidak melepas alat CLI saya ke server produksi begitu saja, saya juga tidak akan membiarkan sesuatu yang belum melewati satu kali pun code review diperlakukan begitu
    • Salah satu pekerjaan software engineering formal pertama saya adalah bekerja di lantai trading sebuah bank, duduk di sebelah trader mata uang
      Yang mempekerjakan saya adalah kepala manajemen risiko pasar, yang tugasnya memastikan bank tidak kehilangan terlalu banyak uang dalam sehari. Ia mempekerjakan saya karena tidak percaya departemen IT resmi yang sudah disetujui akan menulis implementasi algoritmanya dengan benar. Misalnya, mereka pernah salah karena tidak memahami prioritas operator, bahwa perkalian didahulukan daripada penjumlahan
      Perhitungan risiko pasar harus menerima semua transaksi sebagai input, dan karena saat itu awal 2000-an, saya memasang Apache dan Perl CGI di PC di bawah meja dan membuat aplikasi kecil agar para trader bisa memasukkan transaksi dan melacak posisi. Para trader mulai lebih menyukainya daripada solusi IT resmi karena lebih mudah dipakai dan lebih nyaman untuk melihat posisi
      Di banyak lingkungan perusahaan, menemukan cara untuk melewati IT adalah fungsi yang penting. Kembali ke Excel, para trader memakai Excel untuk perhitungan dan simulasi, dan kami menyediakan alat yang terpasang ke Excel agar dapat memanfaatkan pekerjaan yang memang sudah mereka lakukan
    • Ada kalimat dalam artikel yang menyebutkan bahwa ini adalah keputusan kebijakan eksplisit perusahaan
      “Memberikan akses bahasa pemrograman tingkat tinggi kepada pengguna akhir bertentangan dengan visi strategi teknologi perusahaan”
    • Jawabannya adalah ini: karena satu-satunya bahasa pemrograman yang tidak bisa dipilih perusahaan untuk tidak dipasang adalah VBA
      Itulah keajaiban “enterprise”. Saya selalu heran setiap kali orang mengangkatnya seolah-olah itu keunggulan atau alasan pembenar

  • Karena hingga belum lama ini belum ada alternatif yang bagus. Masa depannya ada pada model add-in Office baru: https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...
    Apa pun yang orang katakan tentang TypeScript, setidaknya itu lebih baik daripada VBA. Namun, berbeda dengan VBA, masalah besarnya adalah kita tidak bisa memprogram langsung di dalam Excel. Kadang kita tidak ingin memulai proyek add-in serius yang ditujukan untuk dipakai ulang; kita hanya ingin skrip sekali jalan yang ditulis seadanya untuk memperbaiki sesuatu saat itu juga. Saat mencoba ini, saya menemukan Script Lab(https://learn.microsoft.com/en-us/office/dev/add-ins/overvie...), dan mungkin itu bisa membantu

    • “Berbeda dengan VBA, tidak bisa memprogram langsung di dalam Excel” itu hampir menjadi alasan untuk membatalkan semuanya
      Selain itu ada pertanyaan yang jelas. Bisakah add-in dipasang oleh pengguna tanpa hak istimewa tanpa campur tangan departemen IT? Bisakah itu disertakan di dalam spreadsheet? Jika jawaban untuk yang pertama adalah “tidak”, itu benar-benar fatal; dan jika jawaban untuk yang kedua juga “tidak”, itu tetap berdampak buruk pada adopsi. Kelebihan makro dan VBA adalah, terlepas dari pengaturan keamanan, setiap instans Excel bisa langsung menjalankannya tanpa instalasi tambahan
    • Saya tidak melihat penyebutan Script Lab di akhir komentar. Kalau Microsoft Script Lab, itu memang bisa melakukan hal tersebut: https://www.microsoft.com/en-us/garage/profiles/script-lab/
      Masalah lainnya adalah membagikan add-in kepada pengguna akhir bukan hal sepele. Harus dipublikasikan ke marketplace atau SharePoint, dan sideload memerlukan server SMB serta GPO. Namun ada satu opsi yang jarang disebutkan di mana pun: jika disertakan dalam dokumen, add-in dapat dipasang setelah konfirmasi pengguna saat pertama kali dibuka
    • Untuk sekadar menampilkan UI menarik untuk input data atau visualisasi, ini bagus, tetapi sayangnya OfficeJS bahkan tidak bisa melakukan setengah dari apa yang bisa dilakukan VBA. Kalau saja sistem add-in memiliki FFI, saya pasti sudah beralih untuk selamanya
      Masalah besar lainnya adalah untuk memakai OfficeJS, kita harus bisa meng-host server web. Biasanya sebagian besar pengguna akhir tidak punya akses seperti itu

  • VB(A) mirip dengan Python. Tidak cantik, tetapi menyelesaikan pekerjaan. Jika menurut Anda itu cantik, berarti pengalaman Anda masih kurang sehingga belum banyak tahu alternatif yang lebih baik
    Alat yang memiliki ekosistem bagus—alat, pustaka, dan integrasi—yang memungkinkan pekerjaan nyata diselesaikan itu berguna. Sebagai sistem pengembangan aplikasi desktop, Visual Basic, bersama MS Access dengan keunggulan basis datanya, sangat berguna dalam banyak situasi. Jika kebutuhannya sudah melampaui itu, biasanya sudah ada uang untuk memperluasnya menjadi solusi “sungguhan”
    Tidak diragukan lagi, sistem berbasis VBA telah menghasilkan uang dalam jumlah sangat besar. Dari pengalaman saya melakukan pengembangan finansial terutama sebagai pihak luar, penulisan ulang Excel/VBA terbesar adalah milik sebuah perusahaan yang menghasilkan banyak uang dari credit default swap sekitar 2008. Sebelum ditulis ulang, workbook itu butuh 5 menit untuk dibuka, tetapi VBA mengerjakan banyak pekerjaan berat. Orang-orang yang memiliki pengetahuan itu menghasilkan uang besar dalam bentuk bonus, baik untuk perusahaan maupun untuk diri mereka sendiri
    Pelajaran di sini adalah bahwa yang lebih penting bukan apakah alat itu ideal, melainkan apakah alat itu dapat diakses oleh orang yang tidak dilatih secara khusus untuk menggunakannya. Itu juga alasan Python menjadi nomor satu di luar browser web klien. Bukan berarti ia yang terbaik, tetapi ia menyelesaikan pekerjaan dan mudah diakses

    • Python bisa dibilang bahasa yang cantik; ia bahasa lengkap dengan dukungan class dan first-class function, sekaligus relatif sederhana dan mudah didekati
      Namun itu bukan satu-satunya alasan popularitasnya. Ia memiliki alat data science paling kuat, sehingga efeknya sangat besar, dan juga punya framework web yang layak seperti Django dan Flask. Fakta bahwa banyak universitas menjadikannya “bahasa pertama” menggantikan Java juga menjadi alasan naiknya popularitasnya. VBA tidak seperti itu
    • Python itu cantik, dan menurut saya cara penggunaan whitespace lebih baik daripada strategi penanda blok seperti kurung kurawal, begin/end, atau if/else
      Pengalaman juga berarti menyadari bahwa ada unsur subjektif dalam penilaian cantik atau tidak. VBA berevolusi dalam kondisi yang “keras”, sehingga keanehan-keanehannya sampai batas tertentu bisa dijelaskan
    • Python memang bukan Scheme, tetapi di antara bahasa pemrograman ia jelas termasuk cantik, dan dalam banyak kasus tidak ada alternatif yang lebih baik. Ini berdasarkan sekitar 25 tahun pemrograman dengan puluhan bahasa

  • VBA adalah bahasa yang cukup baik dan mendukung pemrograman berorientasi objek. Tidak ada inheritance, tetapi composition memungkinkan. Ia bisa mengakses dan mengendalikan Excel secara mendalam, serta matang dan stabil. Itu karena Microsoft tidak lagi banyak mengubahnya
    Alasan “programmer sejati” membenci VBA umumnya karena ada banyak kode VBA spaghetti amatiran yang ditulis oleh orang-orang bisnis, dan sesekali programmer diminta men-debug-nya

    • Sebagai sanggahan, VBA adalah bahasa yang buruk, kecuali dalam hal bisa mengakses dan mengendalikan Excel, Word, dan sejenisnya
      Bahasa ini penuh dengan karakteristik aneh, seperti karakter kontrol di dalam kode yang dilokalkan.[1][2] Jika ingin kode berjalan juga pada instalasi non-Inggris, Anda harus memakai placeholder seperti Application.International(xlDecimalSeparator) untuk membuat string yang diteruskan ke fungsi tersebut secara dinamis, dan keterbacaan kode jadi sangat menurun. Ketika kode rusak karena alasan ini, pesan error-nya luar biasa tidak membantu, dan jika developer tidak tahu bahwa ini adalah potensi masalah VBA, mereproduksinya praktis mustahil. Untuk mereproduksinya, Anda harus mengubah bahasa antarmuka ke bahasa yang mungkin tidak Anda ketahui
      Setidaknya di Word, sekitar separuh fungsi paling berguna, seperti menyisipkan paragraf setelah paragraf saat ini, akan rusak jika digunakan pada paragraf terakhir di dalam sel tabel, sehingga dibutuhkan banyak workaround spaghetti
      Jika ingin mengirim dan menerima string teks yang memuat berbagai format, seperti merujuk properti innerHtml dari elemen DOM, itu tidak mudah kecuali memakai pemilihan berbasis skrip yang hacky serta copy/paste
      Ada yang membandingkannya dengan Bash di thread lain, dan saya sebenarnya setuju. Jangan menulis hal yang kompleks dalam bahasa mana pun dari keduanya
      [1] https://stackoverflow.com/questions/20652409/using-vba-to-de...
      [2] https://stackoverflow.com/questions/29832281/vba-range-funct...
    • Saya menghabiskan banyak sekali waktu membuat library VBA (https://github.com/sancarn/stdVBA) dan menyukai VBA, tetapi ada masalah nyata yang menjadi batasan besar bagi bahasa ini (https://sancarn.github.io/vba-articles/issues-with-vba.html)
      Namun, memang benar juga bahwa sebagian besar kebencian terhadap VBA berasal dari kondisi proyek-proyek VBA (https://sancarn.github.io/vba-articles/why-is-vba-most-dread...)
    • Saya rasa wajar jika orang memandang kurang baik lingkungan yang menyertakan fitur keliru seperti On Error Resume Next

  • Jika memikirkan Excel dan spreadsheet secara keseluruhan, banyak orang di luar sana tidak benar-benar memahami betapa baiknya bahasa spreadsheet mengimplementasikan pemrograman fungsional reaktif. Itulah bagian yang masih berusaha dilakukan dengan benar oleh React/Angular selama lebih dari 10 rilis
    Banyak orang juga tidak memahami mengapa spreadsheet begitu nyaman bagi pengguna akhir, dan akibatnya mereka menyediakan UI inferior yang sebenarnya membuatnya lebih sulit
    Terkadang kita perlu mundur selangkah dan memahami bahwa bahkan pada masa ketika belum ada GUI, orang-orang dulu sudah melakukannya dengan benar. Sejak awal pun bisnis tetap berjalan, dan selama sebagian besar waktu, yang dibutuhkan perusahaan adalah tampilan berbentuk tabel serta opsi untuk melakukan kalkulasi fungsi reaktif di atasnya. Coba tanyakan kepada teman yang bekerja di UKM, mereka akan mengonfirmasinya

    • Sebagian besar upaya dalam pengembangan web digunakan untuk presentasi. Jika yang dibutuhkan hanya data, saya setuju bahwa sulit untuk mengalahkan spreadsheet
    • Excel bisa dianggap sebagai IDE untuk pengguna akhir terbaik yang pernah diciptakan