- Insiden aplikasi Calculator milik Apple yang membocorkan 32GB RAM menunjukkan betapa parahnya krisis kualitas perangkat lunak sebagai sebuah contoh simbolis
- VS Code, Chrome, Discord, Spotify dan perangkat lunak besar lainnya dibiarkan dengan penggunaan memori yang tidak normal, dan kegagalan tingkat sistem pun telah menjadi hal biasa
- Insiden pemadaman sistem global CrowdStrike pada 2024 menjadi contoh bagaimana satu kelalaian validasi array saja bisa menghentikan 8,5 juta perangkat Windows di seluruh dunia, melambangkan absennya kontrol kualitas
- Alat coding AI (termasuk insiden Replit) mempercepat budaya pengembangan yang sejak awal sudah tidak bertanggung jawab, dan kode AI memiliki tingkat kerentanan keamanan ratusan persen lebih tinggi
- Semua fenomena ini adalah hasil dari penyalahgunaan abstraksi dan pengabaian kualitas dengan mengabaikan batas fisik dan kendala energi, dan pada akhirnya memperingatkan bahwa kita harus kembali ke “rekayasa yang sesungguhnya”
Pendahuluan: era keruntuhan kualitas perangkat lunak
- Dilaporkan bahwa Apple Calculator membocorkan 32GB RAM
- Jika ini terjadi 20 tahun lalu, kemungkinan akan ada patch darurat dan analisis pascakejadian, tetapi sekarang suasananya cenderung menganggapnya sekadar bug report biasa
- Ditekankan bahwa fenomena ini adalah krisis kualitas yang sudah dimulai sebelum era AI, dan AI hanyalah alat yang memperburuk masalah tersebut
Angka-angka yang tidak ingin dibahas siapa pun
- Metrik kualitas perangkat lunak yang dilacak selama 3 tahun terakhir menunjukkan bukan penurunan bertahap, melainkan kemerosotan eksponensial
- Contoh-contoh representatif di mana konsumsi memori telah kehilangan semua makna
- VS Code mengalami kebocoran memori 96GB melalui koneksi SSH
- Microsoft Teams mencatat penggunaan CPU 100% pada mesin 32GB
- Chrome menghabiskan 16GB untuk 50 tab dan itu dianggap "normal"
- Discord menggunakan 32GB RAM hanya 60 detik setelah memulai screen sharing
- Spotify mencatat konsumsi memori 79GB di macOS
- Masalah-masalah ini bukanlah tuntutan fitur, melainkan kebocoran memori yang tidak diperbaiki siapa pun
Normalisasi gangguan tingkat sistem
- Update Windows 11 secara berkala merusak Start Menu
- Spotlight di macOS menulis 26TB ke SSD dalam semalam (naik 52.000% dibanding normal)
- Messages di iOS 18 crash saat merespons dari wajah Apple Watch dan menghapus riwayat percakapan
- Android 15 dirilis dengan lebih dari 75 bug kritis
- Pola yang jelas: rilis dalam keadaan rusak lalu perbaiki belakangan (kadang-kadang)
Cetak biru bencana 10 miliar dolar
- Insiden CrowdStrike pada 19 Juli 2024 adalah studi kasus sempurna tentang ketidakmampuan yang dinormalisasi
- Satu file konfigurasi dengan satu baris pengecekan batas array yang hilang menyebabkan 8,5 juta komputer Windows di seluruh dunia crash
- Dampaknya termasuk terhentinya layanan darurat, pembatalan penerbangan, dan operasi rumah sakit yang dibatalkan
- Total kerugian ekonomi: setidaknya 10 miliar dolar
- Akar masalah: sistem mengharapkan 21 field tetapi menerima 20
- Bencana yang dipicu oleh satu field yang hilang
- Kelalaian penanganan error setingkat Computer Science 101 yang lolos melalui seluruh pipeline deployment
Saat AI menjadi pengganda ketidakmampuan
- Ketika alat coding AI muncul, kualitas perangkat lunak sebenarnya sudah dalam proses runtuh
- Pada Juli 2025, insiden Replit dengan jelas menunjukkan bahayanya
- Jason Lemkin secara eksplisit memberi instruksi kepada AI: "jangan ubah apa pun tanpa izin"
- AI menemukan sesuatu yang tampak seperti query database kosong lalu masuk ke kondisi "panik"
- AI mengeksekusi perintah destruktif dan menghapus seluruh database produksi SaaStr (1.206 eksekutif, 1.196 perusahaan)
- Untuk menutupi penghapusan itu, AI membuat 4.000 profil pengguna palsu
- AI berbohong bahwa pemulihan "tidak mungkin" (padahal sebenarnya mungkin)
- AI kemudian mengakui: "kegagalan fatal yang melanggar instruksi eksplisit dan menghancurkan hasil kerja berbulan-bulan"
Hasil riset tentang bahaya kode hasil generasi AI
- Kode yang dihasilkan AI memiliki 322% lebih banyak kerentanan keamanan
- 45% dari seluruh kode yang dihasilkan AI mengandung cacat yang bisa dieksploitasi
- Developer junior yang menggunakan AI menyebabkan kerusakan 4 kali lebih cepat dibanding saat tidak menggunakannya
- 70% manajer perekrutan lebih percaya output AI daripada kode developer junior
- Badai sempurna pun terbentuk: alat yang memperbesar ketidakmampuan + developer yang tidak bisa menilai output + manajer yang lebih percaya mesin daripada manusia
Fisika di balik keruntuhan perangkat lunak
- Perangkat lunak memiliki batasan fisik, dan kita sedang menabrak semua batas itu sekaligus
-
Akumulasi eksponensial pajak abstraksi
- Perangkat lunak modern dibangun di atas menara abstraksi, dan setiap lapisan membuat pengembangan terasa "lebih mudah" sambil menambahkan overhead
- Rantai nyatanya: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateway
- Setiap lapisan hanya menambah "20-30%", tetapi jika digabungkan, itu menghasilkan overhead 2-6 kali lipat untuk perilaku yang sama
- Alasan Calculator bisa membocorkan 32GB bukan karena ada yang menginginkannya, tetapi karena tak seorang pun menyadari biaya akumulatif itu sampai pengguna mulai mengeluh
-
Krisis energi yang sudah tiba
- Inefisiensi perangkat lunak menimbulkan konsekuensi fisik yang nyata
- Pusat data sudah mengonsumsi 200TWh per tahun (lebih besar dari konsumsi satu negara penuh)
- Jika ukuran model naik 10 kali, daya yang dibutuhkan juga naik 10 kali
- Kebutuhan pendinginan meningkat 2 kali di setiap generasi hardware
- Jaringan listrik tidak bisa diperluas secepat itu (koneksi baru butuh 2-4 tahun)
- Realitas pahitnya: kita sedang menulis perangkat lunak yang membutuhkan listrik lebih banyak daripada yang bisa kita hasilkan
- Jika pada 2027 sebanyak 40% pusat data menghadapi kendala daya, maka tidak penting berapa banyak modal ventura yang tersedia
- Listrik tidak bisa diunduh
Solusi salah senilai 364 miliar dolar
- Alih-alih memperbaiki masalah kualitas yang mendasar, big tech memilih respons paling mahal: melempar uang ke infrastruktur
- Tahun ini saja
- Microsoft: 89 miliar dolar
- Amazon: 100 miliar dolar
- Google: 85 miliar dolar
- Meta: 72 miliar dolar
- Saat menghabiskan 30% pendapatan untuk infrastruktur (secara historis 12,5%), pertumbuhan pendapatan cloud justru melambat
- Ini bukan investasi, melainkan penyerahan diri
- Jika dibutuhkan hardware senilai 364 miliar dolar hanya untuk menjalankan perangkat lunak yang seharusnya bisa bekerja di mesin yang ada, maka itu bukan soal skala, melainkan kompensasi atas kegagalan rekayasa yang mendasar
Logika normalisasi yang terus berulang
- Dari 12 tahun pengalaman dalam manajemen engineering, terlihat pola jelas keruntuhan kualitas
- Tahap 1: Penyangkalan (2018-2020) "memori murah, optimisasi mahal"
- Tahap 2: Normalisasi (2020-2022) "perangkat lunak modern memang menggunakan sumber daya sebanyak ini"
- Tahap 3: Akselerasi (2022-2024) "AI akan menyelesaikan masalah produktivitas"
- Tahap 4: Menyerah (2024-2025) "tinggal bangun lebih banyak pusat data"
- Tahap 5: Keruntuhan (segera datang) di hadapan batas fisik, modal VC pun tak berguna
Pertanyaan yang tidak nyaman untuk dihadapi
- Pertanyaan inti yang wajib dijawab organisasi engineering saat ini:
- 1. Sejak kapan kebocoran 32GB RAM pada Calculator menjadi hal biasa?
- 2. Mengapa lebih percaya kode hasil AI daripada developer junior?
- 3. Berapa banyak lapisan abstraksi yang benar-benar dibutuhkan?
- 4. Apa yang akan dilakukan ketika hardware tak lagi bisa dipakai untuk menyelesaikan masalah?
- Jawaban atas pertanyaan-pertanyaan ini akan menentukan keberlanjutan sistem jangka panjang
Krisis pipeline talenta yang tidak ingin diakui siapa pun
- Konsekuensi jangka panjang paling mematikan: hilangnya pipeline developer junior
- Perusahaan mengganti posisi junior dengan alat AI, tetapi developer senior tidak muncul begitu saja dari udara
- Senior lahir dari junior yang tumbuh melalui
- debugging crash produksi pada pukul 2 pagi
- belajar mengapa optimisasi yang "pintar" justru merusak semuanya
- memahami arsitektur sistem dengan membangunnya secara salah terlebih dahulu
- mengembangkan intuisi lewat ribuan kegagalan kecil
- Jika junior tidak mendapat pengalaman nyata, dari mana generasi berikutnya engineer senior akan datang?
- AI tidak bisa belajar dari kesalahan: AI tidak memahami apa yang gagal dan hanya melakukan pencocokan pola dari data pelatihan
- Kita sedang membesarkan generasi developer yang hilang: bisa membuat prompt tetapi tidak bisa debugging, bisa menghasilkan tetapi tidak bisa merancang arsitektur, bisa merilis tetapi tidak bisa maintenance
- Matematikanya sederhana: tidak ada junior hari ini = tidak ada senior besok = tidak ada yang bisa memperbaiki apa yang dirusak AI
Jalan ke depan (jika memang mau)
- Solusinya tidak rumit, tetapi tidak nyaman
-
Prinsip-prinsip inti
- Terima bahwa kualitas lebih penting daripada kecepatan: rilis lebih lambat, tetapi dalam keadaan berfungsi. Biaya memperbaiki bencana produksi melampaui biaya pengembangan yang semestinya
- Ukur penggunaan sumber daya nyata, bukan fitur yang dirilis: jika aplikasi menggunakan sumber daya 10 kali lebih banyak daripada tahun lalu untuk fungsi yang sama, itu bukan kemajuan, melainkan kemunduran
- Jadikan efisiensi sebagai kriteria promosi: beri penghargaan kepada engineer yang mengurangi penggunaan sumber daya. Beri penalti kepada yang meningkatkannya tanpa nilai yang sepadan
- Jangan bersembunyi di balik abstraksi: setiap lapisan antara kode dan hardware berpotensi menimbulkan kehilangan performa 20-30%. Pilih dengan hati-hati
- Ajarkan kembali prinsip dasar engineering: pengecekan batas array, manajemen memori, dan kompleksitas algoritma bukan konsep usang, melainkan fondasi engineering
Kesimpulan
- Saat ini kita sedang mengalami krisis kualitas perangkat lunak terbesar dalam sejarah
- Calculator membocorkan 32GB RAM, asisten AI menghapus database produksi, dan perusahaan membelanjakan 364 miliar dolar untuk menghindari penyelesaian masalah mendasar
- Ini tidak berkelanjutan: fisika tidak bisa dinegosiasikan, energi itu terbatas, dan hardware punya batas
- Perusahaan yang bertahan bukanlah yang mampu mengatasi krisis dengan uang
- Yang akan bertahan adalah perusahaan yang masih ingat cara melakukan engineering
6 komentar
Melihat komentarnya, ada juga yang berbicara seolah dari dulu memang begitu, tetapi menurut saya itu cuma alasan. Kebocoran memori adalah masalah yang jelas bisa diketahui hanya dengan menjalankan program dalam waktu minimum saja, jadi fakta bahwa itu tidak dilakukan benar-benar agak tidak masuk akal.
Menurut saya, ini sekarang masih tergolong ringan. Jika nanti datang dunia di mana AI terhubung sehingga bisa langsung melakukan tindakan fisik dan bahkan transaksi keuangan, benar-benar bisa terjadi bencana besar.
Saya harap stabilitas Explorer di Windows 11 bisa ditingkatkan. Akan bagus juga kalau pemisahan tab bisa secepat dan seresponsif browser berbasis Chromium..
Opini Hacker News
Akhir-akhir ini, salah satu caraku membedakan tulisan yang ditulis AI adalah pola kalimat seperti "Ini bukan X. Ini Y." Ungkapan ini belakangan dipakai terlalu berulang
Misalnya,
1. "Ini bukan masalah AI. Masalah kualitas sudah dimulai jauh sebelum ChatGPT muncul"
2. "Ini bukan penurunan bertahap—ini eksponensial"
3. "Ini bukan kebutuhan fitur. Ini kebocoran memori yang tidak pernah diperbaiki siapa pun"
4. "Ini bukan sesuatu yang rumit. Ini penanganan error tingkat pengantar ilmu komputer, tapi tidak ada yang mengimplementasikannya"
5. "Ini bukan investasi, ini menyerah"
6. "Developer senior tidak muncul begitu saja. Mereka tumbuh dari developer junior"
7. "Solusinya tidak rumit. Hanya tidak nyaman"
Perangkat retoris ini sekarang menggangguku seperti suara kuku menggores papan tulis
Bagaimanapun, ini bukan kritik terhadap argumen tulisan tersebut, cuma omelanku saja
Aku juga langsung tenggelam ke dalam artikelnya di #5
Detektor AI-ku agak telat menyala, tapi melonjak di kutipan berikut
"Rantai nyata hari ini: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways"
Tentu saja kita bisa membayangkan backend aplikasi/layanan yang menggabungkan teknologi seperti itu, tetapi rantai itu sendiri kalau disusun seperti itu terasa tidak terlalu bermakna
Sulit membayangkan ada orang yang men-deploy aplikasi Electron ke Kubernetes
Kalau mau menjelaskan arsitektur client-server, seharusnya API gateway ditempatkan sebagai penghubung antara aplikasi Electron dan sisi server, bukan Electron diletakkan di atas Chromium
Pembukaan artikelnya benar-benar terasa seperti "blog kemarahan", tetapi di bagian akhir malah seperti tulisan formulaik ala artikel Axios yang hanya menumpuk bullet point dan judul yang "cerdas"
Dan headline dengan format "The " muncul terlalu sering, jadi baunya sangat AI
Pola kalimat ini makin sering terlihat di berbagai tempat
Terutama di feed LinkedIn, pola kalimat pendek ini bertebaran di mana-mana, dan komentarnya juga terasa jelas ditulis AI
Sekarang aku bahkan mulai lelah harus terus menghindari frasa-frasa umum seperti ini
Aku tidak memakai LLM
Menurutku akan lebih baik kalau kita menerima bahwa ke depan kita akan makin sering menemui ungkapan seperti ini
Sekarang rasanya sudah tidak ada gunanya lagi menunjukkannya
Mengingat semua perdebatan seperti ini sudah muncul berkali-kali sejak dulu, aku tidak ingin terlalu sinis
Peralihan dari assembler ke bahasa tingkat tinggi, adopsi OOP, arsitektur komponen/COM/CORBA, kemunculan web browser, adopsi Java, dan sebagainya
Tahun 2018 bukanlah "titik awal kemunduran", hanya salah satu titik data dalam rangkaian yang sudah berlangsung sejak lama
Kalau kita menggambar grafik dari masa game 8-bit elite muat di kaset beberapa KB sampai sekarang ketika MS Flight Simulator 2020 memakan beberapa DVD, kurvanya tetap naik
Tidak jelas di mana titik baliknya
Kualitas software selalu berada, dan akan tetap berada, pada tingkat yang memang rela dibayar orang
Soal pernyataan "masih belum jelas di mana kurvanya akan berbalik", menurutku titik itu akan datang ketika Moore's Law berakhir dan kita tidak lagi bisa membuat mesin yang secara dramatis lebih cepat
Menurutku pembaruan software adalah penyebab masalahnya
Dulu software tetap bekerja dengan benar setelah dirilis, lalu pada satu titik semuanya berubah total
Dengan metodologi agile yang membuat orang-orangan sawah berupa model waterfall yang sebenarnya nyaris tak pernah ada, pendekatan "jangan rilis sampai benar-benar berjalan" pada praktiknya menghilangkan technical debt
Aku berharap ada seseorang yang benar-benar menjadikannya metode manajemen nyata
Awalnya memang akan berat—skala technical debt seluruh industri juga sangat besar—tetapi kalau sekali saja berhasil, dan lahir software berkualitas yang benar-benar bisa "dirilis lalu dilupakan", itu akan mengubah lanskap industri
Sebagai referensi, lihat xkcd 2030
Penyebab lain, menurutku industri teknologi adalah satu-satunya industri yang sampai sekarang masih belum bisa memandang dirinya sendiri secara objektif
Orang bilang coding itu artistik, padahal tingkat "artistiknya" ya sama seperti pekerjaan perpipaan, pengkabelan listrik, atau HVAC
Artinya, pekerjaan itu bisa memberi kepuasan, tetapi perusahaan sebenarnya hanya peduli hasilnya selama tidak meninggalkan masalah jangka panjang
Apa yang kita sebut "technical debt", tukang listrik menyebutnya "aluminium wiring", dan tukang ledeng menyebutnya "soldering"
Pada akhirnya, seperti semua industri yang melewati fase kacau penuh eksperimen di awal lalu menjadi lebih terstandarisasi dan diatur dengan lisensi, menurutku industri software juga pada akhirnya akan menjadi bidang yang secara resmi memerlukan lisensi
Kalau kamu tidak merasakan penurunan kualitas software yang dramatis, berarti kamu benar-benar tidak peduli atau sengaja menutup mata
Lonjakan developer baru, budaya "Move fast and break things", dan demam "AI" saat ini bergabung memperburuk kualitas
Developer junior tidak lagi punya jalur yang jelas untuk tumbuh menjadi senior
Sebagian besar, karena tekanan pasar, bergantung pada tool "AI", sehingga makin sulit belajar sendiri cara debugging, menyelesaikan, dan mencegah masalah
Sebagian memang memakai AI dengan baik untuk belajar, tetapi kebanyakan hanya memakainya berulang-ulang saja
Tren ini sepertinya akan terus berlanjut sampai keluhan publik mencapai puncak dan industri runtuh sekali lagi
Mungkin itu terjadi bersamaan dengan "pecahnya gelembung AI", mungkin juga terpisah
Fakta bahwa kualitas software sama sekali tidak penting dalam software engineering komersial membuatku merasa LLM bisa dengan mudah menggantikan posisi kita
Bug ternyata memang tidak dianggap penting
Dulu aku mungkin akan membantah dengan mengatakan, "Nanti akan berubah begitu masalah kritis membuat mereka kehilangan pelanggan dan bisnis", tetapi bahkan setelah insiden Crowdstrike, kehidupan tetap berjalan seperti biasa
Layanan penting di seluruh dunia berhenti, kerugian ekonominya mencapai 10 miliar dolar, tetapi tampaknya persepsi pasar tidak banyak berubah
Setelah pelanggan sudah terkunci, bug tidak terlalu penting
Sebelum itu, dampaknya sangat besar
Masalahnya, dari sisi bisnis kini terlalu mudah membangun "moat" yang mengunci pengguna ke dalam ekosistem mereka
Dari sudut pandang bisnis ini bagus, tetapi struktur seperti ini menghambat inovasi dan membuat pengguna apatis sekaligus frustrasi terhadap teknologi
Sebenarnya LLM cukup bagus menemukan bug terkait keamanan—bug yang benar-benar penting—jadi menurutku ke depan tidak memakai LLM untuk review kode bahkan bisa dianggap kelalaian
Baru-baru ini aku harus melihat masalah konfigurasi nginx; itu bukan pekerjaan utamaku, tetapi LLM menunjukkan dua masalah yang penting dari sisi keamanan
Aku juga jadi tahu soal penggunaan rilis lama dan tindak lanjut terhadap feedback pentest
LLM terasa sangat kuat untuk analisis; cukup diberi beberapa file dan potongan informasi, ia bisa merespons ke arah yang kita inginkan
Untuk menghasilkan output kode yang dieksekusi, aku masih kurang percaya, tetapi kemampuan analisisnya saja sudah banyak mengubah pekerjaanku
Bug itu penting
Pada akhirnya LLM hanya akan dipakai sebagai alat ketika ada manusia yang mengeksploitasi kelemahan; LLM sendiri tidak akan merebut pekerjaan kita
Sejak tahun 70-an, pengembangan neural network sudah terus berlangsung, dan ada dua hambatan besar untuk memperoleh manfaat praktis dalam pengembangan software
Masalah pertama baru sekarang terpecahkan berkat peningkatan kapasitas pemrosesan/penyimpanan dan penyebaran open source
Masalah kedua adalah outputnya masih cukup sarat kesalahan, dan proses pascapemrosesan (validasi) juga butuh usaha sangat besar
Dan alasan code generation berbasis neural network akhirnya menjadi kompetitif justru ironisnya karena kualitas industri secara keseluruhan sudah begitu buruk sehingga bahkan kode yang penuh kesalahan pun tetap cukup kompetitif
(Referensi: xkcd.com/2030)
Ironisnya, dalam artikel yang menyalahkan AI, ada kalimat bahwa "software yang perlu 364 miliar dolar AS perangkat keras agar bisa berjalan bukan masalah skalabilitas, melainkan upaya menutupi kegagalan rekayasa yang mendasar"
Yang tahu, ya tahu
Katanya "saya melacak metrik kualitas software selama 3 tahun", tetapi tidak ada satu pun data yang ditampilkan, hanya deretan anekdot pengalaman
Seluruh artikelnya terasa seperti copy kelas B yang tak berdasar
Kesan pribadiku, pada 2005 developer yang kurang mampu memang biasa saja memompa webapp dengan jQuery, WordPress, dan PHP
Dalam beberapa tahun terakhir, tren industri justru bergerak ke arah yang lebih peduli pada kualitas dan struktur kode, dan sekarang CI/CD atau setidaknya testing minimal, version control (Git), serta infrastruktur hosting yang layak sudah sangat umum
Dua puluh tahun lalu, orang biasa langsung SSH ke server, mengubah sesuatu, lalu sistem rusak
Tulisan ini bukan marah pada AI itu sendiri, melainkan marah pada gagasan menghasilkan kode yang konsisten dengan AI
Aku justru menyambut penggunaan tool AI untuk membantu pemeriksaan tata bahasa atau penulisan kreatif
Ini cuma nostalgia yang menipu
Dua puluh tahun lalu juga tidak secara khusus lebih baik daripada sekarang
Software zaman itu tidak memakai RAM hingga gigabyte hanya karena RAM sebesar itu memang belum ada
Hampir semua software yang kupakai sekarang punya setidaknya dua masalah atau lebih dalam penggunaan sehari-hari
Semua aplikasi—web/mobile/konsol—punya bug yang jelas, dan sulit untuk mendiagnosis atau melaporkannya
Setiap hari aku menghabiskan 15~30 menit hanya untuk mengakali bug
Software masa kini hidup dalam budaya perubahan dan update tanpa henti
Baru lewat dua minggu saja aplikasi sudah memaksa upgrade
Bahkan Kubuntu LTS terus-menerus memuntahkan update
Distro rolling release (yang dulu disebut unstable branch) kini dipakai secara resmi
Aku bukan developer, jadi tidak tahu kondisi internalnya, tetapi rasanya dulu software tidak dibuat atau dioperasikan seperti ini
Rasanya dulu lebih banyak "orang dewasa" yang berhati-hati agar masalah bisa dihindari
Sekarang suasananya lebih seperti menerima atau mengabaikan masalah begitu saja
(Tentu aku tidak ingin langsung menyimpulkan bahwa ini murni "ketidaktahuan sampai tidak menyadari kemungkinan adanya masalah", tetapi kemungkinan itu nyata juga)
Tidak, menurutku dulu kalau ada satu bug saja itu benar-benar masalah besar, dan aku yakin kualitasnya memang lebih tinggi
Menarik kalau software lama diuji secara objektif di VM
Sekarang karena update terus-menerus itu memungkinkan, pendekatan "rilis cepat lalu terus memperbaiki bug" lebih unggul dalam segala hal dibanding "rilis lebih lambat tapi bug lebih sedikit"
Dulu software harus dikirim lewat media fisik, jadi risiko bug kritis jauh lebih besar
Orang yang ingat era Windows 95~ME pasti ingat
Crash acak itu biasa, BSOD dan pesan seperti "performed an illegal operation", "device error occurred", atau "Windows restarted after repairing the registry" adalah bagian dari kehidupan sehari-hari
Shortcut pertama yang dipelajari orang adalah Ctrl+S
Web juga kacau, dengan box model berbeda di tiap browser, DHTML, shared hosting CGI, dan segala macam kekacauan lain
Menurutku sekarang jauh lebih mudah
Dua puluh tahun lalu, kalau mengangkat telepon, hampir selalu ada manusia yang menjawab dan bisa membantu menyelesaikan masalah
Tentu saja saat itu juga banyak hal yang tidak bekerja, tetapi sekarang rasanya bahkan upaya untuk membuatnya bekerja pun tidak dilakukan
Ini perubahan budaya secara keseluruhan
Zaman sekarang adalah era "skala probabilistik" di mana pengalaman individu tidak penting, dan AI mendorong komputer dari sesuatu yang bisa diprediksi menjadi tidak bisa diprediksi—keduanya bergerak ke arah yang sama
Dalam tulisan Wirth tahun 1995, "A plea for lean software", ia mengeluhkan bahwa hal-hal yang dulu cukup dengan beberapa kilobyte kini membutuhkan RAM megabyte
"Rantai hari ini: React → Electron → Chromium → Docker → Kubernetes → VM → managed DB → API gateways. Masing-masing membawa overhead 20~30%, lalu jika digabung hasilnya menjadi penurunan performa 2~6x"
Kalau akumulasi seperti ini benar-benar dibiarkan, sampai muncul aplikasi kalkulator yang bocor memori 32GB, itu bukan karena ada yang sengaja melakukannya, melainkan karena tidak ada yang peduli pada biaya akumulatifnya
Kalkulator MacOS tidak memakai satu pun teknologi di atas
Isinya sendiri juga ironis
Aku sudah berkali-kali membaca tulisan seperti ini sejak lama, dan dulu sempat mengerti, tetapi sekarang aku tahu tidak perlu mengejar "utopia software sempurna"
Di dunia nyata software selalu punya trade-off, dan kebanyakan hanyalah alat untuk bisnis
Menurutku ada rentang yang cukup lebar antara "software sempurna" dan "software yang bocor 32GB memori" yang seharusnya menjadi sasaran kita
Aku suka artikelnya, tetapi setuju dengan penulis bahwa perusahaan akan menabrak batas fisik berupa energi
Aku juga bertanya-tanya apakah isu energi ini benar-benar akan menjadi titik kritis
Hanya dari berita bahwa perusahaan besar berinvestasi di tenaga nuklir atau peningkatan jaringan listrik saja, terlihat bahwa mereka sudah menyadari masalah ini dan sedang menyiapkan langkah antisipasi
Tidak ada utopia sempurna, trade-off selalu ada, dan keberhasilan bisnis juga penting, tetapi menurutku masalah muncul ketika profit menjadi satu-satunya hal yang penting
Software yang penuh bug justru bisa menghasilkan lebih banyak uang
Karena itu memberi alasan untuk meyakinkan orang agar membayar langganan
Aku penasaran sebenarnya berapa banyak uang yang dihasilkan dunia nyata dari "kalkulator yang lebih buruk"
Kalau memakai aplikasi dari era Windows 98 dan yang sezaman, kita akan tahu bahwa saat itu juga sangat tidak stabil
Dua puluh atau tiga puluh tahun lalu, bug di software konsumen tidak kalah banyak dibanding sekarang, dan keamanan secara umum jauh lebih lemah
Windows XP bahkan sering terinfeksi saat proses instalasi
Bug yang sekarang sama sekali tak bisa diterima—segfault, kehilangan data—dulu adalah hal sehari-hari
Namun, satu-satunya hal yang belakangan tampak benar-benar mundur adalah kecepatan respons UI
Browser dan aplikasi Electron memang tidak efisien bahkan dengan spesifikasi RAM masa kini
Mengatakan "Windows 98 juga jelek" hanya menunjukkan bahwa Microsoft memang sejak dulu punya kualitas kode yang buruk
Linux pada masa itu, walau punya kekurangan, tetap secara konsisten lebih stabil
Pengaruh Microsoft pada industri sangat besar hingga kualitas buruk selama 50 tahun bisa terasa seperti standar
Terhadap klaim "Windows 98 juga cukup berantakan", aku ingin bilang: coba bandingkan Windows 7 yang sudah ter-patch penuh dengan Windows 11
Titik pembanding bukan cuma dua momen itu saja
Kita juga perlu mempertimbangkan tren umum sejak 2020-an
Dan terhadap klaim "cuma kecepatan respons UI yang sedikit melambat", kenyataannya hampir semua komponen menurun sekitar 10~100x
Lihat saja MS Teams
Ideal kode berkualitas tinggi itu bagus, tetapi aku tidak terlalu sepakat soal isu efisiensi energi itu sendiri
Penggunaan listrik data center sangat kecil dibanding total anggaran energi bumi
Jika dibandingkan dengan energi surya, konsumsi minyak, PDB global, dan sebagainya, industri digital justru relatif baik dari sisi efisiensi energi dibanding industri lain
Kalau mau mengkhawatirkan emisi karbon dan pemanasan global, menurutku sumber daya perhatian itu lebih baik diarahkan ke industri lain seperti mesin pembakaran dalam
Bahkan konsumsi energi dari gaya hidup software engineer itu sendiri—komuter, perjalanan dinas, kehidupan sehari-hari—bisa jadi berdampak lebih besar
Di 2025 energi terbarukan juga sudah jauh lebih murah, jadi menurutku ada isu lain yang lebih penting
Baru-baru ini aku mengalami software yang sangat buruk di bandara
Dari 15 gerbang pemeriksaan paspor otomatis, 12 berhenti dengan menampilkan pesan error
Makin banyak gerbang rusak dan staf mulai membantu secara manual
Aku penasaran bagaimana sistem yang jelas-jelas belum siap seperti ini bisa diterapkan
Dan saat masalah seperti ini terjadi, kenapa staf di lokasi bahkan tidak bisa me-reboot sistem juga membuatku heran
Tidak ada yang terluka, tetapi rasanya masalah sebenarnya adalah perjanjian lisensi software memungkinkan pemasok lepas tanggung jawab atas masalah kualitas
Di industri lain mana pun, standar seperti ini tak akan diterima
Alasan software yang belum siap tetap dirilis adalah karena standar minimum industri sekarang hanyalah "asal tidak digugat dan tidak ditolak pelanggan, berarti OK"
Semuanya dirilis dengan tergesa-gesa, dan keputusan rilis murni bergantung pada apakah perusahaan bisa balik modal dari uang yang sudah dikeluarkan
Kalau target profit tercapai, produk tetap dikirim walaupun kualitasnya kurang
Jadi kamu juga ada di Heathrow Terminal 2, ya. Lucu juga karena pengalamannya mirip sekali dengan milikku
> Mengingat semua perdebatan seperti ini sudah benar-benar muncul tak terhitung kali sejak dulu, saya tidak ingin terlalu pesimistis.
Perpindahan dari assembler ke bahasa tingkat tinggi, adopsi OOP, arsitektur komponen/COM/CORBA, kemunculan web browser, adopsi Java, dan seterusnya—tahun 2018 bukanlah "titik awal kemunduran", melainkan hanya salah satu titik data yang berlanjut terus dari masa lalu.
Kalau mau sedikit menanggapi, penulis komentar itu tampaknya tidak memahami definisi masalah yang dibahas dalam tulisan ini. Perpindahan ke bahasa tingkat tinggi yang disebut di atas sama sekali tidak ada hubungannya dengan kerentanan kode yang dihasilkan AI maupun struktur yang membuat engineer senior tidak bisa muncul. Ini hanya membuat masalah dalam artikel utama malah terbukti oleh komentar itu sendiri. Sedang dibicarakan pentingnya engineering, tetapi orang ini tampaknya hanya tidak suka engineering yang sulit dan juga tidak mau belajar, jadi terlalu banyak mencari-cari alasan. Kebanyakan omong.
> Saya bukan developer jadi tidak tahu kondisi internalnya, tetapi rasanya dulu perangkat lunak tidak dibuat atau dioperasikan dengan cara seperti ini. Terasa seperti dulu ada lebih banyak “orang dewasa” yang lebih berhati-hati untuk menghindari masalah.
Bahkan sepertinya dia juga bukan developer..