- Pengguna lebih mementingkan produk berfungsi daripada sifat intrinsik kode itu sendiri, tetapi kode yang buruk memiliki dampak turunan langsung pada performa, bug, dan kecepatan pengembangan
- Ungkapan “pengguna tidak peduli pada tech stack atau testing” secara dangkal memang benar, tetapi semakin rendah kualitas kode, semakin sulit dan lambat memperbaiki bug serta menambahkan fitur
- Seperti analogi inspeksi jembatan, pilot mabuk, dan fondasi bangunan yang tidak stabil, meskipun pengguna tidak melihat proses itu sendiri, hasilnya tetap memengaruhi keamanan dan keandalan
- Latar belakang mengapa anggapan seperti ini populer bisa jadi melibatkan mekanisme pertahanan ego untuk meremehkan hal-hal yang tidak terlalu dikuasai seseorang
- Pekerjaan perangkat lunak yang serius adalah campuran dari berbagai perhatian dan sudut pandang, dan semuanya berkontribusi pada berhasil atau gagalnya hasil, sehingga kualitas kode tidak boleh dianggap remeh
Klise yang Terus Berulang dan Batasannya
- Di industri perangkat lunak, ucapan seperti
- “Pelanggan tidak peduli pada testing, mereka hanya peduli apakah produknya berfungsi”
- “Pengguna tidak peduli pada tech stack”
- “Keanggunan rekayasa tidak sama dengan nilai pasar”
- “Pengguna tidak peduli apakah itu ditulis AI atau manusia, atau framework apa yang dipakai; mereka hanya peduli apakah produknya berfungsi”
terus diulang
- Semua ucapan ini adalah variasi dari tema yang sama: “pelanggan tidak peduli soal itu”
- Seolah-olah, pragmatis berpengalaman sedang memberi tahu para idealis atau mereka yang picik tentang kenyataan dunia yang dingin
- Namun, semua itu omong kosong (horseshit), dan
jika logika yang sama diterapkan ke bidang lain, celahnya akan terlihat- Pengguna jalan tidak peduli apakah jembatan sudah menjalani inspeksi akhir, mereka hanya peduli apakah jembatan itu menopang mobil mereka
- Penumpang tidak peduli apakah pilotnya mabuk, mereka hanya peduli apakah pesawat tiba tepat waktu
- Pekerja kantoran tidak peduli apakah fondasi gedung tinggi itu stabil, mereka hanya peduli menghasilkan uang
- Analogi-analogi ini secara permukaan memang benar, tetapi mengabaikan dampak turunan (downstream effects) yang jelas
Dampak Turunan yang Diabaikan
- Benar bahwa pelanggan tidak tertarik pada sifat intrinsik kode komputer, tetapi
kualitas kode memengaruhi performa, ada tidaknya bug, waktu perbaikan bug, dan waktu penambahan fitur - Semakin buruk kodenya, semakin sulit dan semakin lambat menyelesaikan masalah-masalah ini
- Perusahaan seperti AirBnB, OpenAI, dan Meta dapat memaksakan diri melewati kekhawatiran semacam ini karena dominasi pasar yang besar, dukungan VC yang masif, dan legalitas yang meragukan
tetapi jika bukan perusahaan seperti itu, akan lebih sulit menutup-nutupi masalah dengan cara yang sama
Kebertahanan ‘Folk Wisdom’ dan Beragam Perhatian dalam Perangkat Lunak
-
Daya Tahan Anggapan Umum (The Persistence of Folk Wisdom)
- Gagasan bahwa hanya efek tingkat pertama yang penting telah menjadi anggapan umum yang sangat populer dalam perangkat lunak
- Orang cenderung mendiskon atau mengecilkan hal-hal yang tidak mereka kuasai dengan baik
- Jika seseorang merasa tidak cukup mampu membuat kode yang baik, ia mudah mengambil pandangan bahwa kode yang baik bukan saja tidak penting, tetapi orang-orang yang mampu membuat kode yang baik justru adalah masalahnya
- Dalam sudut pandang seperti itu, orang-orang yang menghambat rilis karena hal-hal yang tidak dipedulikan pelanggan diperlakukan seolah merekalah masalahnya
- Sikap ini berfungsi sebagai mekanisme pertahanan ego (ego defence mechanism) untuk menghindari kelemahan diri sendiri dan melempar tanggung jawab ke orang lain
-
Kita Hidup dalam Masyarakat (We Live in a Society)
- Pekerjaan perangkat lunak yang serius adalah campuran dari perhatian yang berbeda-beda dan sudut pandang yang berbeda-beda
- Dari tech sales hingga tech stack, dari pengalaman pengguna (UX) hingga pengenal unik (unique identifiers), banyak unsur masuk ke dalam upaya perangkat lunak
- Semua unsur ini berkontribusi pada keberhasilan atau kegagalan
1 komentar
Komentar Lobste.rs
Kalimat seperti ini bisa baik atau buruk, baik dalam cara penyampaiannya maupun cara membacanya
Misalnya, pernyataan “pelanggan sama sekali tidak peduli pada testing. Mereka peduli apakah produk bekerja” bisa dibaca bukan sebagai “rilis saja bug”, melainkan sebagai ajakan untuk lebih fokus pada produk yang benar-benar bekerja daripada ideologi testing tertentu
Testing adalah salah satu cara untuk membuat kode bekerja, jadi kalau cakupan testing tinggi dan semua lolos tetapi produknya tidak jalan, itu tetap gagal; sebaliknya, kalau produk bekerja dengan baik lewat cara selain testing, itu juga tidak masalah, dan meski tidak mengikuti doktrin formal, selama bug tertangani dengan baik, itu juga bisa diterima
Selain itu, dari sudut pandang pengguna dan bisnis, “produk/fitur tidak ada” juga bisa menjadi bug, jadi perbaikan bug yang ada dan peluncuran fitur tidak selalu terpisah rapi
Namun, dalam praktiknya, saya juga pernah mendengar kalimat seperti ini dipakai dengan maksud “cari jalan pintas dan rilis sampah”
Saya sepenuhnya menolak gagasan bahwa pemrograman yang buruk itu “praktis” bahkan jika dilihat dalam rentang beberapa bulan
Membangun fitur baru di codebase dengan desain buruk dan testing minim itu lambat dan mahal
Developer perlu sadar apakah mereka menghabiskan waktu di tempat yang menciptakan nilai, dan idealnya manajemen juga memahami mengapa pekerjaan seperti itu dilakukan
Ketika kurangnya pemahaman bertemu dengan struktur insentif yang keliru, hasil akhirnya adalah “cari jalan pintas dan rilis sampah”
Sejujurnya, orang yang mengatakan hal seperti ini sering kali justru terlihat seperti orang yang juga tidak terlalu peduli pada pengguna
Agar pengguna benar-benar menerima produk yang berfungsi, proses pengembangan harus punya mekanisme yang meningkatkan kemungkinan itu; saya sudah mengatakan hal ini juga di komentar beberapa hari lalu
Sentimen seperti ini sering muncul dalam situasi ketika pengguna tidak punya cara yang layak untuk memberi umpan balik tentang produk, dan bahkan tidak ada metrik penggunaan yang nyata
Ada banyak skenario kegagalan yang memengaruhi pengguna meskipun mereka tidak langsung melihat atau memedulikannya
Contoh paling jelas adalah keamanan: sampai datanya muncul di dump kebocoran online, pengguna bisa saja tidak peduli bahwa sistem itu “tidak aman”, dan performa juga mungkin tidak terasa sebagai masalah sampai mereka tahu bahwa sebenarnya bisa jauh lebih baik
Sulit mendapat hasil yang baik dengan memilih satu elemen saja dari proses perbaikan lalu mengoptimalkannya, tetapi untuk mendorong kemajuan dalam diskusi, sering kali itu tetap harus dilakukan
Karena itu, akan membantu jika diskusinya dikalibrasi sambil menyelaraskan jalur umpan balik dengan letak masalah yang terlihat sebenarnya
Saya melihat tulisan seperti ini sebagai upaya untuk mengingatkan orang pada unsur-unsur yang memengaruhi keberhasilan proyek perangkat lunak, meskipun unsur-unsur itu tampak saling eksklusif
Menjabarkan dan membela hal-hal yang biasanya hanya dipahami secara intuitif oleh orang yang punya kepekaan teknis itu bernilai, tetapi banyak teknolog tampaknya belum mampu menyeimbangkan pekerjaan yang tak terlihat atau meyakinkannya secara efektif, dan saya sendiri juga masih terus berlatih dalam hal itu
Memperhatikan bagian internal itu penting, dan pada praktiknya juga menguntungkan pengguna
Saya suka sudut pandang ini
Saya juga tidak ingin jatuh ke ekstrem sebaliknya, yaitu overengineering, tetapi saya berharap kita bisa keluar dari pola pikir “bergerak cepat dan merusak”
Dari pengalaman saya, ini nyaris seperti wabah di dunia web development
Saya justru berharap masuknya perangkat lunak berkualitas rendah yang dimungkinkan oleh LLM akan membuat pengguna lebih menghargai perangkat lunak yang andal
Saya makin menjadi developer grug brain, jadi saya tidak tahu apakah ini perasaan yang umum, tetapi saya lelah dengan “ayo tambah satu fitur lagi”
Kita terlalu sering membuat kesalahan dengan mengukur biaya software hanya dari tanggal rilis, dan hampir tidak memasukkan biaya pemeliharaan sepanjang umur pakainya
Orang berkata, “Tidak sulit kok, bahkan tidak sampai seminggu!” tetapi tidak menyebut waktu 2–4 minggu per tahun yang nanti akan habis untuk pemeliharaan, perbaikan, perluasan, pembaruan, integrasi, dan dokumentasi
Saya sering mengatakan hal yang nadanya mirip
“Pengguna akhir tidak peduli apakah software punya 100% test coverage, atau ditulis 100% dalam assembly tanpa dokumentasi dengan label seperti
lbl0. Mereka peduli pada akurasi, performa, dan pengalaman pengguna”Tetapi software engineering justru membantu kita mencapai tujuan itu dengan lebih mudah dan menjaga kualitas tetap pada level yang baik
Masalahnya, jalur ini juga bisa berujung pada cargo cult dan overengineering, dan saya jelas juga bersalah soal itu
Tetap saja, pada akhirnya kita harus memberikan nilai nyata kepada pengguna
Seperti Boeing dan Airbus, ada hasil optimal yang bisa dibuktikan
Kenapa pesawat kedua perusahaan itu terlihat begitu mirip, siapa yang mendesain lebih dulu, dan siapa yang meniru siapa, bukanlah pokok persoalannya
Tidak ada yang meniru; engineer terbaik dunia dari tim yang berbeda, ketika merancang di bawah kendala yang sama, akan sampai pada desain yang menyimpang darinya dan secara definisi menjadi lebih buruk
Anda harus berada di Pareto frontier, kalau tidak ya akan tersingkir
Di bidang kita juga ada titik optimal di suatu tempat; pertanyaannya adalah apakah kita punya alat, anggaran, dan orang yang tepat untuk mencapainya, serta apakah kita punya cukup banyak pengguna untuk benar-benar tahu bahwa kita sudah sampai di sana atau belum