Ini bukan bug, ini fitur — esensi, asal-usul dan perbedaan

Apa arti "Ini bukan bug, ini fitur"

"Ini bukan bug, ini fitur" — frasa yang digunakan pengembang atau manajer untuk menunjukkan bahwa perilaku program yang tidak terduga adalah disengaja, bukan kesalahan. Dalam kasus klasik, ini adalah lelucon: semua orang memahami bahwa perilaku tersebut salah, tetapi menyebutnya "fitur" untuk meredakan ketegangan. Namun dalam proyek nyata, frasa ini juga digunakan dengan serius — ketika perilaku benar-benar sesuai dengan spesifikasi tetapi tidak sesuai dengan harapan pengguna.

Perbedaan antara bug dan fitur seringkali subjektif. Bagi pengembang yang menulis kode, perilaku tertentu mungkin tampak logis. Bagi pengguna — tidak terduga dan salah. Subjektivitas persepsi — alasan utama mengapa frasa ini begitu bertahan. Ia memungkinkan perpindahan pembicaraan dari ranah "siapa yang bersalah" ke ranah "sudah dirancang demikian". Menurut UX Collective, 40% bug yang dilaporkan oleh pengguna sebenarnya adalah masalah UX, bukan kesalahan kode.

Dalam tim agile, frasa ini sering digunakan sebagai mekanisme pertahanan saat demo. Pengembang menunjukkan perilaku yang tidak terduga, product owner mengerutkan kening, dan frasa sakramental "ini bukan bug, ini fitur" terdengar. Kepercayaan dalam tim menentukan apakah frasa akan diterima sebagai lelucon atau upaya menyembunyikan masalah. Dalam tim yang sehat, lelucon semacam itu mencairkan suasana; dalam tim yang toksik, ia memicu konflik.

Sejarah munculnya frasa ikonik

Penggunaan pertama yang diketahui dari frasa ini tercatat pada tahun 1976 di salah satu buletin DECUS (Digital Equipment Corporation User Society). Seorang pengguna mengeluh bahwa prosesor teks RUNOFF salah memproses baris kosong. Jawaban pengembang: "Ini bukan bug, ini fitur — begitulah cara paragraf diproses". Sejak itu, frasa tersebut menjadi simbol pembelaan kode yang ditulis "apa adanya", terlepas dari kualitas sebenarnya.

Popularitas frasa ini didorong oleh Jargon File — kamus slang hacker yang pada tahun 1990-an menjadi dasar buku "The New Hacker's Dictionary". Dalam Jargon File, entri "feature" secara langsung merujuk pada bug yang menjadi fitur karena ketidakmungkinan atau keengganan untuk memperbaikinya. Contoh: tombol Caps Lock di terminal awal tidak memiliki indikator — itu adalah bug yang menjadi fitur "untuk mengetik buta".

Pada tahun 2000-an, frasa ini merambah budaya populer melalui meme internet. Gambar kucing dengan tulisan "It's not a bug, it's a feature" menyebar di forum dan media sosial. Dalam industri game, frasa ini sangat sering digunakan: glitch yang tidak mengganggu gameplay dinyatakan sebagai "fitur" untuk atmosfer. Fenomena budaya telah melampaui IT — frasa ini dapat didengar dalam konteks apa pun di mana kesalahan dibenarkan.

Psikologi alasan: mengapa mereka berkata demikian

Dasar psikologis dari frasa ini adalah disonansi kognitif. Pengembang telah menghabiskan berjam-jam menulis kode, dan mengakui bahwa hasilnya salah berarti merendahkan pekerjaan sendiri. Frasa "ini bukan bug, ini fitur" mengurangi disonansi: kesalahan berubah menjadi keputusan yang disengaja, dan pengembang — dari yang bersalah menjadi pencipta ide. Ini adalah mekanisme pertahanan psikis yang menjaga harga diri.

Alasan kedua — takut pengerjaan ulang. Jika bug diakui, harus melalui code review, pengujian, dan deploy lagi. "Fitur" tidak memerlukan perbaikan — tugas ditutup, beban berkurang. Menurut Microsoft Research, pengembang secara sadar menurunkan tingkat keparahan bug untuk menghindari pengerjaan ulang dalam 23% kasus. Frasa ini adalah bentuk ringan dari penurunan tersebut.

Alasan ketiga — budaya perusahaan. Di beberapa perusahaan, bug diperhitungkan dalam KPI pengembang, dan ditemukannya bug saat code review dianggap sebagai kesalahan penulis. Dalam lingkungan seperti itu, frasa "ini bukan bug, ini fitur" adalah cara untuk menghindari konsekuensi negatif bagi karier. Budaya kesalahan yang sehat (blameless culture) menghilangkan alasan ini: jika bug tidak dihukum, lebih mudah untuk mengakuinya.

Di mana batas antara bug dan fitur

Batas yang jelas hanya ada dengan adanya Acceptance Criteria (kriteria penerimaan). Jika perilaku tidak sesuai dengan poin AC mana pun — itu bug. Jika perilaku sesuai dengan AC tetapi tidak disukai pengguna — itu masalah UX, bukan bug. Jika AC tidak ada — perilaku apa pun dapat dinyatakan sebagai fitur, dan ini adalah alasan utama bertahannya frasa ini.

Aturan praktis: bug — ketika program melakukan apa yang seharusnya tidak dilakukan atau tidak melakukan apa yang seharusnya dilakukan sesuai spesifikasi. Fitur — ketika program melakukan apa yang dirancang, bahkan jika hasilnya mengejutkan pengguna. Kasus kontroversial: undefined behavior (bahasa tidak menentukan hasil), race conditions (muncul tidak stabil), nilai ekstrem (berfungsi untuk 99% data).

Untuk membedakan, gunakan matriks keputusan:

• Perilaku dijelaskan dalam spesifikasi dan diimplementasikan dengan benar — fitur, bahkan jika tidak disukai
• Perilaku dijelaskan tetapi diimplementasikan salah — bug, memerlukan perbaikan
• Perilaku tidak dijelaskan tetapi logis dari kebutuhan — fitur tidak terdokumentasi, harus ditambahkan ke spesifikasi
• Perilaku tidak dijelaskan dan tidak logis — bug, memerlukan klarifikasi kebutuhan

Kasus paling berbahaya — ketika spesifikasi tidak ada dan pengembang sendiri memutuskan apa itu fitur. Dalam proyek semacam itu, kesalahan apa pun dapat dinyatakan sebagai "fitur", membuat kode tidak dapat diprediksi untuk seluruh tim. Acceptance Criteria yang jelas untuk setiap tugas — satu-satunya cara untuk menarik batas secara objektif.

Bahaya pertukaran konsep dalam tim

Bahaya pertama — pengaburan kualitas. Jika setiap bug dapat dinyatakan sebagai fitur, tim tidak memiliki insentif untuk menulis kode berkualitas. Kesalahan tidak diperbaiki, utang teknis bertambah, dan pengguna terbiasa dengan "perilaku aneh". Cepat atau lambat pesaing meluncurkan produk yang dapat diprediksi dan pengguna pergi.

Bahaya kedua — konflik dalam tim. Insinyur QA menemukan bug, pengembang berkata "ini fitur". Jika tidak ada kriteria objektif (Acceptance Criteria), perselisihan beralih ke ranah pribadi: "kamu salah menguji" vs "kamu salah memprogram". Menurut PractiTest State of Testing 2023, perselisihan "bug vs fitur" adalah salah satu dari tiga penyebab utama gesekan antara QA dan pengembang.

Bahaya ketiga — risiko hukum. Di industri yang diatur (medis, keuangan, penerbangan), konsep "bug" dan "fitur" memiliki bobot hukum. Jika dalam perangkat lunak medis suatu perilaku dinyatakan sebagai fitur tetapi menyebabkan perhitungan dosis yang salah — ini bukan lelucon, melainkan pelanggaran persyaratan regulasi. Sistem safety-critical tidak memaafkan pertukaran konsep, oleh karena itu selalu diterapkan formal verification di dalamnya.

Cara mencegah kebingungan antara bug dan fitur

Alat utama — Acceptance Criteria (AC) yang jelas di setiap tugas. AC ditulis sebelum pengembangan dimulai: "Setelah memasukkan X, sistem harus menghasilkan Y". Jika perilaku tidak dijelaskan — itu adalah bug secara default, bahkan jika pengembang berpikir sebaliknya. AC harus terukur dan dapat diverifikasi: "tombol hijau" — buruk, "HEX #00FF00" — baik.

Alat kedua — Definition of Done dalam tim. Deskripsi yang jelas tentang apa artinya "tugas selesai": kode ditulis, tes ditulis, tes lulus, code review selesai, di-deploy ke staging, diuji oleh QA. Jika semua poin DoD terpenuhi tetapi pengguna mengeluh — ini bukan bug, melainkan missed requirement yang masuk ke backlog sebagai fitur baru.

Alat ketiga — budaya blameless post-mortem. Jika bug dinyatakan sebagai fitur dan masuk ke produksi — kami menganalisis penyebabnya, bukan mencari siapa yang bersalah. Mengapa pengembang memutuskan bahwa ini adalah fitur? Mengapa QA melewatkannya? Mengapa AC tidak lengkap? Jawaban atas pertanyaan-pertanyaan ini memperbaiki proses, bukan menghukum orang. Perbaikan sistemik bekerja lebih efektif daripada melarang frasa "ini bukan bug, ini fitur".