Perangkat lunak yang baik tahu kapan harus berhenti

• Peran hakiki perangkat lunak adalah mengetahui dengan jelas masalah yang harus diselesaikannya dan menyadari batas-batasnya
• Perangkat lunak yang baik tidak berusaha memuat semua fitur, hanya menangani bagian yang memang perlu ditingkatkan, dan tidak menyimpang dari tujuannya
• Mengajukan contoh imajiner di mana perintah ls digantikan dengan fitur AI, sambil menyindir fenomena perluasan alat lama yang tidak perlu
• Mengutip prinsip-prinsip dari ‘Getting Real’ dan ‘Rework’ karya 37Signals untuk menekankan bahwa keterbatasan harus dijadikan keunggulan dan permintaan fitur yang tidak perlu harus ditolak
• Mengingatkan bahwa bahkan di tengah demam AI, stabilitas standar yang sudah ada dan definisi masalah yang jelas memiliki nilai lebih besar daripada tren baru

---

Peran dan batas perangkat lunak

• Tulisan ini dimulai dengan adegan imajiner setelah memperbarui distribusi Linux, di mana perintah ls berubah menjadi kecerdasan direktori berbasis AI
  • Perintah baru als memprediksi niat pengguna, memberi peringkat pada file, dan menampilkan pesan bahwa ls lama akan dihentikan dukungannya dalam 30 hari
  • Adegan ini adalah sindiran terhadap kelebihan fitur dan inovasi yang tidak perlu
• Sambil mengatakan “syukurlah hal seperti ini tidak benar-benar terjadi”, tulisan ini menekankan bahwa perangkat lunak yang baik tahu kapan ia harus berhenti

Prinsip inti perangkat lunak yang baik

• Perangkat lunak yang baik mengetahui tujuan apa yang dijalankannya, tidak berusaha melakukan semuanya, dan mampu membedakan kapan harus berhenti serta apa yang perlu diperbaiki
• Pola pikir maksimalis manusia cenderung membuat segala sesuatu menjadi lebih besar dan lebih rumit
• Namun, perangkat lunak harus mendefinisikan peran dan posisinya dengan jelas, dan jika ide baru tidak sesuai dengan visi yang ada, ide itu harus dipisahkan menjadi proyek terpisah

Filsafat produk 37Signals

• ‘Rework’ dan ‘Getting Real’ yang ditulis para pendiri Basecamp memberikan pelajaran penting dalam perancangan produk
  • Keterbatasan adalah keunggulan (Constraints are advantages): tim kecil, anggaran terbatas, dan cakupan terbatas mendorong pengambilan keputusan yang lebih baik
  • Abaikan permintaan fitur (Ignore feature requests): alih-alih langsung menerapkan fitur yang diminta pengguna, diperlukan pendekatan untuk memahami masalah mendasarnya
  • Rilis lebih awal dan lebih sering (Ship early, ship often): produk yang belum sempurna tetapi benar-benar bekerja lebih berharga daripada produk sempurna yang tidak pernah dirilis
  • Desain berpusat pada inti (Epicenter design): rancang antarmuka inti dan interaksi utamanya terlebih dahulu, bukan navigasi atau elemen pinggiran
  • Katakan ‘tidak’ sebagai default (Say no by default): fitur baru membawa biaya tersembunyi berupa kompleksitas, biaya pemeliharaan, dan bertambahnya penanganan pengecualian
  • Buat apa yang Anda sendiri butuhkan (Scratch your own itch): produk yang memecahkan masalah yang benar-benar Anda butuhkan memungkinkan pengambilan keputusan yang lebih baik

Nilai keberlanjutan dibanding perubahan

• Belakangan ini ada arus di mana banyak produk merombak nama dan fungsinya dengan AI sebagai pusat
  • MinIO → AIStor
  • Oracle Database → Oracle AI Database
• Tidak semua hal perlu berubah secara dramatis
• Menjadi standar de facto dalam area masalah tertentu memiliki nilai yang lebih besar

[GN⁺]

Komentar Hacker News

• Saat melihat saran “abaikan permintaan fitur”, saya teringat kasus Blizzard dan World of Warcraft Classic
  Selama bertahun-tahun pengguna meminta versi klasik, tetapi Blizzard menolak dengan mengatakan, “kalian tidak akan menginginkannya”
  Pada akhirnya mereka merilis WoW Classic dan meraih kesuksesan besar
  Belakangan tim pengembang mengakui bahwa “pengguna benar-benar tahu apa yang mereka inginkan”
  Jadi, alih-alih selalu mengabaikan permintaan fitur, kita perlu mengakui bahwa kadang pengguna bisa saja benar-benar tepat

  • Meski permintaan pengguna awalnya terasa tidak masuk akal, jika itu datang dari pengguna yang sopan, saat menjelaskan mengapa hal itu tidak bisa dilakukan kita kadang justru memikirkan solusi yang lebih baik
    Sebaliknya, pengguna yang kasar atau egois membuat percakapan itu sendiri melelahkan sehingga akhirnya tidak ditanggapi
    Pelajarannya adalah, saat meminta sesuatu, lakukan dengan sopan
  • Ungkapan “abaikan permintaan pengguna” terdengar bagus di permukaan, tetapi yang lebih tepat sebenarnya adalah “pahami apa yang sedang dikatakan pengguna”
    Setelah itu, barulah menilai apakah itu permintaan yang valid, lalu memikirkan cara mengimplementasikannya
  • Jika melihat kasus Blizzard, yang diinginkan pengguna sebenarnya bukan sekadar versi klasik, melainkan penolakan terhadap sistem WoW modern yang kompleks
    Masalah dasarnya adalah ‘game yang telah kehilangan rasa aslinya’, dan jika ini dipahami, sebenarnya itu bisa diselesaikan dengan cara lain selain Classic
  • Kenyataannya, baik pengguna, pengembang, maupun PM sering kali tidak benar-benar tahu dengan jelas apa yang sebenarnya mereka inginkan
    WoW Classic adalah ekspresi dari keinginan yang dangkal untuk mendapatkan kembali ‘nuansa lama’, tetapi di bawahnya ada ketidakpercayaan terhadap ‘arah pengembangan yang tidak bisa diandalkan’
    Dalam dunia ideal, mungkin ada bentuk sempurna yang menggabungkan kelebihan dua versi, tetapi di dunia nyata itu kemungkinan hanya akan menambah kekacauan karena benturan pendapat
  • Contoh sebaliknya adalah Ultima Online
    Ketika instance non-PVP ditambahkan mengikuti permintaan pengguna, ketegangannya hilang dan game menjadi hambar
    Dalam kasus ini, pengembang rupanya memang lebih tahu daripada pengguna

• Saya rasa perlu ada lebih banyak perangkat lunak yang selesai dan berhenti menambah fitur
  Dibutuhkan keberanian untuk berkata, “segini sudah cukup”
  Ada banyak contoh seperti Evernote atau Dropbox yang setelah masa terbaiknya justru menjadi membingungkan karena kelebihan fitur

  • Dulu sebenarnya sebagian besar perangkat lunak dirilis dengan cara seperti itu
    Dijual dalam kotak, dan ketika versi baru keluar kita membeli kotak baru
    Itu adalah masa sebelum web app yang terus-menerus diperbarui seperti sekarang
  • Sebagian besar perangkat lunak tidak mau mengakui bahwa ia sudah selesai
    Malah sering kali semakin buruk setiap kali diperbarui
    Produk yang benar-benar membaik jumlahnya sangat sedikit
  • Baru setelah membaca komentar terkait, saya memahami mengapa fenomena ini terjadi
  • Dropbox kehilangan tujuan sederhananya semula, lalu kembali menjadi network filesystem yang rumit
    Pada akhirnya ia malah menciptakan kembali masalah yang dulu ingin diselesaikannya
  • Dulu ada aplikasi to-do iOS sederhana bernama Task Eater, dan pengembangnya menyatakan “sekarang sudah selesai” lalu berhenti memperbaruinya
    Tetapi seiring waktu aplikasi itu tidak lagi kompatibel dengan versi iOS baru dan akhirnya tidak bisa digunakan
    Saya merasakan sekaligus keindahan dari sesuatu yang selesai dan kekejaman evolusi teknologi

• Saat saya beralih dari menangani infrastruktur menjadi pengembang Java pada 2020, library-library utama berada dalam mode maintenance sehingga saya sempat berpikir, “apakah Java sudah mati?”
  Namun belakangan saya sadar itu berarti sudah matang secara fitur
  Itu adalah kondisi stabil di mana begitu banyak edge case sudah diselesaikan
  Masalahnya, orang tidak menginginkan stabilitas seperti itu dan selalu menginginkan hal baru
  Akhirnya framework yang sama terus dibuat ulang hanya dengan mengganti bahasanya

  • Banyak orang takut memakai library yang sedang maintenance karena khawatir bug tidak akan diperbaiki
    Karena itu mereka lebih menyukai proyek yang masih aktif dikembangkan
    Ada juga perusahaan yang, karena persyaratan compliance, hanya bisa memakai perangkat lunak yang terus diperbarui
  • Dulu saya pernah mengganti library memcached di Java ke Redis karena library itu sudah masuk maintenance
    Saya bercanda, “ini cuma sudah selesai jadi tidak ada lagi yang perlu diperbaiki”, tetapi akhirnya tetap diganti

• Alasan saya menyukai Sublime Text adalah karena kesederhanaan dan kecepatannya
  Ia tidak memasukkan AI atau fitur yang rumit, dan fokus pada satu tujuan

  • Karena itu saya masih memakai vim

• Perangkat lunak yang baik tidak selalu berarti perangkat lunak yang menghasilkan uang
  Tetapi untuk menghasilkan uang, tetap dibutuhkan fitur yang benar-benar dipakai orang
  Karena setiap pengguna memakai 20% fitur yang berbeda, keragaman itu perlu dipertimbangkan

• Saya dulu menganggap Notepad.exe sebagai contoh utama perangkat lunak yang selesai,
  tetapi saya terkejut karena di Windows 11, untuk mengubah asosiasi file diperlukan manipulasi yang nyaris seperti peretasan

  • Tetapi ada juga yang menganggap Notepad sebagai contoh buruk
    Jika melihat blog Windows Insider dan
    pengumuman keamanan,
    masalahnya justru karena pembaruan yang tidak tahu kapan harus berhenti

• Saya mengakui keindahan perangkat lunak yang selesai, tetapi sekarang kebanyakan berada dalam status “beta abadi”
  Karena koneksi internet diasumsikan selalu ada, muncul struktur bahwa “pembaruan bisa dilakukan kapan saja”,
  dan perbaikan bug tidak dipisahkan dari penambahan fitur yang tidak diinginkan
  Pada layanan web seperti YouTube, bahkan memilih versi pun tidak mungkin

  • Saya pindah dari Evernote ke Obsidian, tetapi Obsidian juga makin lama makin berlebihan fiturnya
    Terutama setelah fitur Canvas ditambahkan, filosofi kesederhanaan aslinya mulai goyah
    Jika itu open source, mungkin saya akan mem-fork-nya pada titik itu

• Signal gratis, open source, dan berfokus pada privasi sehingga fiturnya sedikit
  Tapi justru itu yang saya suka

  • Meski begitu, fitur penjadwalan kirim satu ini jauh lebih berguna daripada yang ada di WhatsApp
    WhatsApp justru terus menambah fitur yang tidak perlu

• Dulu saya tidak memahami pentingnya ‘hal-hal yang selalu dibutuhkan (evergreen)’ dalam buku 37signals, terutama kecepatan
  Tetapi seiring waktu, melihat aplikasi makin lama makin lambat, saya jadi sadar betapa besar nilai perangkat lunak yang cepat

• Saya teringat kalimat dalam 『REAMDE』 karya Neal Stephenson, “para penulis menyukai tempat tinggal”
  Seperti para penulis yang terus menciptakan pekerjaan untuk mempertahankan tempat tinggal mereka, pengembang juga cenderung mengubah kode demi menciptakan pekerjaan

  • Saya sudah tak terhitung mendengar kalimat seperti “codebase ini harus ditulis ulang total dengan arsitektur X atau bahasa Y”
    Pada akhirnya, kita juga terus mengulangi perubahan demi perubahan itu sendiri