Pengguna Tidak Peduli — Tapi Anda Harus Peduli

• Pengguna lebih mementingkan produk yang berfungsi daripada sifat intrinsik kode itu sendiri, tetapi kode yang buruk memiliki dampak turunan langsung pada performa, bug, dan kecepatan pengembangan
• Ungkapan seperti “pengguna tidak peduli pada tech stack atau pengujian” mungkin benar secara dangkal, 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, meski pengguna tidak melihat prosesnya secara langsung, hasilnya tetap memengaruhi keamanan dan kepercayaan
• Perusahaan seperti AirBnB, OpenAI, dan Meta bisa memaksakan masalah ini lewat dominasi pasar, dukungan VC yang sangat besar, dan legalitas yang meragukan, tetapi tidak semua perusahaan berada di posisi seperti itu
• Keberhasilan software adalah hasil dari berbagai kepentingan dan sudut pandang yang bekerja bersama, mulai dari sales, tech stack, pengalaman pengguna, hingga pengenal unik

---

Klise yang Terus Berulang dan Batasannya

• Di industri software, ungkapan seperti “pelanggan tidak peduli pada pengujian, mereka hanya peduli apakah produknya bekerja”, “pengguna tidak peduli pada tech stack”, “keanggunan rekayasa tidak sama dengan nilai pasar”, dan “pengguna tidak peduli apakah ditulis AI atau manusia, atau framework apa yang dipakai; mereka hanya peduli apakah produknya bekerja” terus diulang
• Semua ungkapan ini adalah variasi dari tema yang sama: “pelanggan tidak peduli soal itu”, dan disajikan seolah-olah sebagai pragmatisme yang menyampaikan realitas dingin
• Jika logika yang sama diterapkan ke bidang lain, kedangkalan masalahnya menjadi terlihat
  • Pengguna jalan tidak peduli pada inspeksi akhir jembatan; mereka hanya peduli apakah jembatan itu bisa menopang mobil
  • Penumpang tidak peduli apakah pilot mabuk; mereka hanya peduli apakah pesawat tiba tepat waktu
  • Pekerja kantoran tidak peduli pada kestabilan fondasi gedung tinggi; mereka hanya peduli menghasilkan uang
• Analogi-analogi ini secara permukaan memang benar, tetapi mengabaikan dampak turunan yang jelas
• Memang benar pelanggan tidak tertarik pada sifat intrinsik kode komputer, tetapi kualitas kode memengaruhi performa, ada atau tidaknya bug, waktu perbaikan bug, dan waktu penambahan fitur
• Semakin buruk kodenya, semakin sulit dan semakin lambat menyelesaikan masalah-masalah ini
• Ada pendapat bahwa perusahaan seperti AirBnB, OpenAI, dan Meta dapat memaksakan kekhawatiran ini lewat dominasi pasar yang sangat besar, dukungan VC yang melimpah, dan legalitas yang meragukan
• Kesimpulannya, jika Anda bukan perusahaan seperti itu, akan lebih sulit menutupi masalah dengan cara yang sama

Kebertahanan ‘Kebijaksanaan Umum’ dan Beragam Kepentingan dalam Software

• Kebertahanan kebijaksanaan umum

  • Gagasan bahwa hanya efek tingkat pertama yang penting adalah keyakinan populer yang sangat kuat dalam dunia software
  • Orang cenderung meremehkan atau mengecilkan hal-hal yang tidak mereka kuasai
  • Jika seseorang merasa tidak mampu membuat kode yang baik, ia mudah mengambil sudut pandang bahwa kode yang baik bukan saja tidak penting, tetapi orang yang bisa membuat kode yang baik justru adalah masalahnya
  • Dalam sudut pandang seperti itu, orang-orang yang menghambat rilis demi hal-hal yang tidak dipedulikan pelanggan dianggap sebagai masalah
  • Sikap ini berfungsi sebagai mekanisme pertahanan ego untuk menghindari kelemahan diri dan mengeksternalisasi tanggung jawab kepada orang lain

• Kita hidup dalam masyarakat

  • Pekerjaan software yang serius adalah campuran dari kepentingan yang berbeda dan sudut pandang yang berbeda pula
  • Dari technical sales hingga tech stack, dari pengalaman pengguna hingga pengenal unik, banyak elemen masuk ke dalam upaya software
  • Semua elemen ini berkontribusi pada keberhasilan atau kegagalan

[GN⁺]

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”

  • Soal poin bahwa “dari sudut pandang pengguna dan bisnis, produk/fitur yang tidak ada juga merupakan bug”, ada bagian yang sebagai penulis belum sempat saya bahas secara eksplisit
    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
  • Ada juga banyak engineer yang berpikir “semakin banyak unit test semakin baik” atau menghabiskan berhari-hari mengoptimalkan kode yang bahkan bukan bottleneck, jadi dalam kasus seperti itu, tafsir-tafsir di atas cukup tepat
    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

  • Topik seperti ini memang sulit dijelaskan ke audiens umum
    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