Saya skeptis terhadap low-code

• Saya bersikap skeptis terhadap low-code
• Saat bekerja di bidang konsultasi perangkat lunak, saya sering bertemu klien yang tertarik oleh iklan yang menjanjikan waktu pengembangan cepat dan biaya pemeliharaan rendah dari low-code
• Ada beberapa alasan mengapa klien tidak merasa puas

Keterbatasan untuk fitur kustom

• Solusi low-code memenuhi sekitar 80% kebutuhan perusahaan, tetapi 20% sisanya tidak dapat diselesaikan dengan fitur bawaan
• Pemasar alat low-code mengklaim bahwa 20% sisanya dapat diselesaikan dengan mudah, tetapi pada praktiknya diperlukan kustomisasi yang signifikan dan kadang itu tidak mungkin
• Perusahaan harus memilih apakah fitur bawaan alat tersebut sudah cukup mendekati kebutuhan mereka, atau mencoba mengakali alat itu agar sesuai dengan use case yang benar-benar mereka butuhkan

Keterbatasan kumpulan developer

• Perusahaan kadang mencoba mengakali alat low-code agar dapat memenuhi 100% kebutuhan mereka
• Akibatnya, banyak kode kustom ditulis untuk alat tertentu atau bahasa proprietari, sehingga sangat sedikit developer yang bisa memahaminya
• Kini perusahaan, alih-alih merekrut dari kumpulan developer bahasa open source yang digunakan luas, harus mencari pemelihara yang sangat terspesialisasi pada alat ini

Masalah upgrade platform

• Sulit melakukan upgrade perangkat lunak tanpa merusak hal-hal yang terintegrasi dengannya
• Alat low-code harus menangani kode arbitrer untuk use case yang memang tidak dirancang untuk ditangani oleh alat low-code
• Secara teori hal ini harus bisa dilakukan melalui kontrak API yang ketat, tetapi dalam praktiknya saya sering melihat kode kustom melakukan berbagai macam trik di balik layar

Kekacauan struktur database

• Saya melihat perusahaan menggunakan alat low-code untuk proses yang menuntut analisis presisi
• Namun ketika melihat model data dasarnya, kondisinya sulit dipahami: apa arti user_attribute_47? Jika memindahkan field dari halaman 1 aplikasi ke halaman 2, datanya tersimpan di field yang terpisah?

Pendapat GN⁺

• Low-code adalah alat yang menjanjikan untuk meningkatkan kecepatan pengembangan dan menurunkan biaya pemeliharaan, tetapi dalam penggunaan nyata dapat muncul masalah yang tidak terduga.
• Terutama ketika dibutuhkan fitur kustom atau penggunaan bahasa pengembangan yang bergantung pada alat low-code tertentu, hal ini membatasi kumpulan developer dan menyulitkan pemeliharaan.
• Upgrade alat low-code dan kompleksitas struktur database menjadi pertimbangan penting dalam pengelolaan proyek jangka panjang.
• Tulisan ini memberikan wawasan menarik dengan menyoroti hal-hal yang perlu diperhatikan saat menggunakan alat low-code, serta menganjurkan evaluasi yang cermat terhadap use case yang tepat.

[ats62]

Saya skeptis terhadap low-code

Saya rasa konsep no-code sejauh ini hanya diterapkan secara terbatas pada bidang tertentu.

Kalau muncul layanan yang benar-benar matang dengan memanfaatkan LLM, saya merasa yang perlu didahulukan adalah perubahan pada tren no-code? arusnya? kecenderungannya? entahlah, pokoknya perubahan pada konsepnya.

[quack337]

Sekitar 10 tahun lalu, saya mengetahui sebuah contoh pemanfaatan MS Access yang berguna.

Dalam sistem informasi organisasi, ada database yang dirancang dengan cukup baik dan diimplementasikan di MS Sql Server,
dan pekerjaan OLTP sehari-hari juga diimplementasikan dengan cukup baik.

Namun, ketidakpuasan menumpuk karena respons departemen TI yang lambat dan kurang proaktif terhadap permintaan penelusuran data yang tidak rutin serta pencetakan laporan.

Seorang karyawan dari departemen bisnis yang sangat mahir menggunakan MS Excel dan Access menunjukkan bahwa dengan mengimpor data Excel yang diunduh dari sistem informasi ke Access, ia dapat mewujudkan fungsi penelusuran data dan pencetakan laporan yang dibutuhkan hanya dalam beberapa jam dengan Access, tanpa perlu coding.

[quack337]

Divisi bisnis meminta agar mereka bisa terhubung langsung ke DB dari Access, dan departemen TI menentang pemaparan DB sistem informasi ke jaringan eksternal. Namun, karena tuntutan dari divisi bisnis sangat kuat, dibuatlah DB terpisah yang mencerminkan hanya sebagian data lalu diekspos.

Karyawan yang mahir menggunakan fitur data Excel mulai memanfaatkan Access untuk pekerjaan mereka hanya setelah beberapa hari pelatihan.

[tequila]

Saya cukup relate dengan tulisan ini. Menurut pendapat pribadi saya,
kalau memakai sintaks khusus -> perlu learning curve, dan maintenance jadi sulit
kalau UI hanya sekadar menggantikan kode -> sering kali justru lebih nyaman langsung ngoding
kalau menjadi tool no-code yang sepenuhnya lengkap -> batasannya banyak, dan mendorong pengguna untuk melakukan hacking. Frekuensi pengguna yang membuat perilaku di luar maksud awal pun meningkat drastis
hasilnya: jadinya alat yang tidak bisa memuaskan siapa pun.
Kesenjangan antara perencanaan-pengembangan-pengguna terlalu besar, jadi ini terasa seperti bidang yang lebih sulit dibuat dengan baik daripada yang dibayangkan.

[GN⁺]

Opini Hacker News

• Berbagai sudut pandang tentang low-code

  • Sudut pandang pengembang platform low-code

    Low-code mudah dijual. Strateginya adalah menjadikan departemen IT sebagai masalah dan memanfaatkan ketidakpuasan yang sudah ada. Dalam demo, pekerjaan sederhana ditunjukkan dengan cepat. Namun, sebaiknya logika bisnis inti tidak dimasukkan ke dalam low-code. Diasumsikan bahwa pekerjaan yang kompleks akan di-offload ke sistem khusus. Berguna bagi tim di perusahaan besar yang punya pengetahuan teknis tetapi sedikit otoritas IT. Low-code menyelesaikan banyak masalah dengan alat sederhana, tetapi skalabilitasnya rendah dan harus bekerja sama dengan sistem pusat yang kuat.

  • Sudut pandang SRE (site reliability engineer)

    Skeptis terhadap low-code. Manajemen source code kurang baik, dan dokumentasinya buruk. Banyak custom code dibutuhkan tetapi reusability-nya rendah. Memerlukan runtime proprietary dan sulit dimonitor. Dalam praktiknya, belum pernah melihat kasus di mana engineer yang mengerjakan sementara non-engineer yang memakainya. Alat seperti Looker bisa terintegrasi dengan source code, tetapi tetap saja digunakan oleh engineer. Low-code memang memadatkan kompleksitas, tetapi lebih memilih platform yang dapat dikustomisasi dan diperluas sesuai kebutuhan.

  • Pandangan tentang platform low-code Microsoft

    Tertarik pada platform low-code MS, tetapi tampaknya dibangun secara rumit di atas O365 dan Azure. Antarmuka penggunanya buruk, dan dalam jangka panjang kerugian akibat masalah usability bisa lebih besar daripada penghematan biaya.

  • Pengalaman bisnis memigrasikan solusi database/formulir MS-Access

    Membangun bisnis yang mengubah solusi MS-Access buatan non-developer/pengguna akhir tanpa melalui departemen IT menjadi aplikasi client/server .net yang sesungguhnya. Solusi low-code berguna untuk menyelesaikan sebagian masalah atau membuat POC berjalan, tetapi bisa menimbulkan masalah saat perlu diskalakan atau diadaptasi.

  • Sudut pandang pengembang website builder SQLPage

    Solusi low-code harus memiliki jalan keluar untuk berinteraksi dengan API eksternal "high-code". Di SQLPage, ini disediakan melalui sqlpage.exec. Ada masalah bahwa upgrade platform low-code dapat merusak implementasi kustom. Sebagian besar alat low-code menyandera data, tetapi SQLPage menambahkan lapisan di atas database yang tetap sepenuhnya bisa dikendalikan pengguna.

  • Pendapat yang menentang alat low-code tingkat enterprise

    Menentang alat low-code yang digunakan perusahaan besar. Perusahaan besar seharusnya mampu memiliki tim pengembangan, perencanaan, dan organisasi yang memadai. Bukan kode yang menimbulkan biaya, melainkan developer buruk yang menggunakan alat buruk untuk mengambil keputusan buruk.

  • Pandangan tentang low-code dan lapisan abstraksi

    "Low-code" memang memiliki permukaan kode yang bisa diinteraksikan secara langsung lebih kecil, tetapi sebenarnya banyak kode tersembunyi di baliknya. Lapisan abstraksi sangat kuat jika cocok dengan tujuannya, tetapi bisa menimbulkan masalah jika bocor atau tidak sesuai. Secara umum, low-code mengabstraksikan kode yang disesuaikan untuk penggunaan tertentu, tetapi pada praktiknya tetap membutuhkan pengalaman domain tertentu.

  • Pengalaman membangun MVP dengan Bubble/Airtable

    Menerima estimasi biaya pembuatan MVP dari tim Ukraina, tetapi kemudian mempekerjakan intern untuk membuat produk dengan Bubble/Airtable dalam dua bulan dan mendapatkan pelanggan berbayar dalam enam bulan. Selama hampir dua tahun, tidak menemukan alasan untuk pindah ke stack tradisional.

  • Kisah horor mengembangkan kursus pembelajaran dengan low-code

    Sebuah perusahaan penting menggunakan paket perangkat lunak pembuatan kursus pembelajaran low-code untuk mengembangkan kursus internal bagi staf pemasaran dan penjualan. Beberapa tahun kemudian, kursus itu perlu diperbarui, tetapi muncul masalah karena tidak ada lagi perangkat lunak yang digunakan saat pengembangan maupun alat untuk melakukan pekerjaan tersebut.

  • Pertanyaan tentang kemungkinan version control pada implementasi low-code

    Mempertanyakan apakah implementasi low-code bisa dimasukkan ke version control, apakah akar masalah bisa dilacak saat terjadi isu, dan apakah bisa rollback ke commit tertentu dengan alat gratis. Dalam kebanyakan kasus, fitur-fitur ini tidak tersedia sehingga tidak cocok untuk penggunaan serius.