Mengapa perangkat lunak masih dirilis dengan bug yang dikenal? [Tutup]

Tampaknya sering dalam proyek-proyek besar perangkat lunak masih dirilis dengan pelacak bug yang penuh bug. Sekarang saya dapat memahami permintaan fitur, tetapi beberapa kali saya telah melihat sejumlah besar bug masih belum terselesaikan, tidak ditinjau, atau belum selesai tetapi rilis masih didorong keluar.

Mengapa? Mengapa proyek open source atau proyek pada umumnya dirilis dengan bug yang dikenal ? Mengapa mereka tidak menunggu sampai pelacak bug memiliki 0 bug yang dibuka?

Sejumlah alasan, termasuk:

1. Perusahaan telah membuat komitmen pada basis pengguna untuk dirilis pada waktu tertentu
2. Bug tidak kritis-misi, atau bahkan besar
3. Pengembangan fitur baru dipandang lebih penting (apakah benar atau tidak)

Untuk sebagian kecil, ini seperti bertanya mengapa Anda bekerja sebagai programmer meskipun pengetahuan pemrograman Anda tidak "lengkap". Dalam sebagian besar proyek yang kompleks, akan ada banyak bug. Berurusan dengan mereka sambil menambahkan fitur baru adalah tugas yang sulit dan kompleks.

Karena perangkat lunak dengan bug lebih baik daripada tidak ada perangkat lunak sama sekali.
Untuk alasan yang sama:

• Perusahaan transportasi repot membuat jadwal, meskipun selalu ada penundaan.
• Perusahaan farmasi menjual obat dengan efek samping yang diketahui (dan sebagian besar didokumentasikan).
• Sekolah-sekolah di seluruh dunia mengajarkan fisika Newton, meskipun ia memiliki keterbatasan.

Memiliki solusi dengan defisiensi yang diketahui jauh lebih baik daripada tidak memiliki solusi, atau memiliki solusi dengan defisiensi yang tidak diketahui.
IDE favorit saya memiliki banyak fitur segar, yang jauh dari stabil. Katakan saja: Saya lebih suka, harus melakukan sesuatu dengan tangan setiap kali kedua puluh, karena fitur gagal, daripada harus melakukan semuanya dengan tangan.

Atau mengatakannya dengan kata-kata Voltaire: "Le mieux est l'ennemi du bien."

Pada akhirnya, ini adalah keputusan bisnis, bahkan untuk perangkat lunak bebas dan sumber terbuka. Ada titik di mana cacat yang ada memiliki dampak rendah yang lebih baik untuk dirilis, bawa perangkat lunak Anda ke tangan pengguna, dan dapatkan umpan balik (termasuk, tetapi tidak terbatas pada, permintaan fitur dan laporan bug baru dari cacat tidak ditemukan) dalam pengujian). Keputusan ini didorong oleh kebutuhan untuk mendapatkan daya tarik di pasar untuk perangkat lunak di antara para pesaing. Jika Anda ingin perangkat lunak Anda memberi dampak, Anda harus mengalahkan pesaing Anda untuk memasarkan dengan fitur atau konsep baru.

semuanya bermuara pada analisis biaya vs. manfaat. Setiap perbaikan bug memiliki beberapa nilai biaya yang terkait dengannya (jam kerja untuk memperbaikinya, risiko membuat lebih banyak perubahan kode X hari sebelum rilis ...). Pada saat yang sama, setiap perbaikan bug dengan jelas membawa nilai tambahan dalam hal lebih banyak fitur, kegunaan, dll.

Jadi ini pertanyaan yang dihadapi setiap tim pengembangan ketika membuat rilis: 1) apakah Bug #i layak diperbaiki mengingat biaya dan nilai tambahan dan 2) ulangi untuk semua bug terbuka mulai dari i = 0 hingga N.

Perlu diingat bahwa produk perangkat lunak yang tidak dirilis tidak memiliki nilai bagi siapa pun. Produk perangkat lunak yang memiliki 200 bug luar biasa tetapi memiliki 90% fungsinya berfungsi, memiliki nilai bagi semua orang yang senang dengan apa yang berfungsi pada saat rilis.

Saya tidak pernah di perusahaan mana pun pada produk apa pun yang dirilis dengan 0 bug dan saya pikir itu sangat normal. Pada titik tertentu, Anda hanya memotong kerugian Anda dan memanfaatkan apa yang berhasil. Kalau tidak, Anda tidak akan pernah merilis apa pun.

Dalam proyek besar, Anda tidak pernah berhenti menemukan bug. Jika Anda harus menunggu sampai semua bug diperbaiki dan regresi perbaikan diuji, Anda tidak akan pernah melepaskannya.

Juga, perhatikan bahwa tidak semua bug bersifat internal. Setiap program adalah bagian dari web kompleks perangkat lunak lain, dan perubahan di tempat lain dapat memanifestasikan dirinya sebagai "bug" dalam perangkat lunak Anda. Anda tidak bisa menghentikan dunia.

Selain banyak jawaban bagus, terkadang ada perlombaan memasarkan dengan produk baru. Jika Anda pikir Anda bisa mendapatkan sebagian besar pangsa pasar meski dengan 15% (atau jumlah lainnya) cacat terbuka, mungkin ada baiknya melepaskan produk untuk mendapatkan keunggulan pada pesaing.

Bug ini mungkin sangat kecil. Ingat bahwa perangkat lunak komersial perlu dikirim, dan ditekan pada disk, dan hal-hal semacam itu. Memenuhi tanggal rilis memiliki implikasi keuangan yang serius, dan menunda untuk beberapa masalah kecil bukanlah masalah finansial - belum lagi kebutuhan untuk pergi ke pasar karena alasan lain.

Jawaban potensial:

• Sangat tidak mungkin bagi siapa pun untuk menemukan bug.
• Ada solusi untuk bug.
• Perangkat lunak perlu dirilis kapan-kapan, dan kesempurnaan tidak mungkin tercapai.

Saya yakin idealnya kebanyakan pengembang ingin melihat bug nol dalam aplikasi mereka, sayangnya kondisi mungkin tidak memungkinkan untuk keadaan utopia seperti itu.

Saya ingin percaya itu karena basis pengguna menuntut fitur-fitur baru dan bersedia untuk mengambil bug yang sama atau lebih untuk fungsionalitas tambahan.

Jika ada manajemen yang terlibat, tenggat waktu harus dipenuhi karena berbagai alasan - jadwal iklan, masalah ketersediaan staf tambahan, pola pikir "kita-harus-menjadi-yang-pertama-dengan-fungsi-ini".

Kurang optimis dalam pikiran saya, mungkin karena pengembangnya malas?

Juga ingat bahwa dalam komunitas open-source biasanya "siapa" yang ingin mengambil permintaan bug / fitur / masalah apa - mungkin tidak ada yang mau berurusan dengan masalah yang ada karena masalah yang lebih besar di belakang mereka.

Dalam uji program paling sederhana:

if (management->perceived_cost_to_fix > management->perceived_benefit_release_now) {
    release;
}

Semuanya selalu merupakan trade-off, apakah itu memperbaiki bug, waktu / ruang / memori, atau keamanan / kegunaan. Pikirkan tentang perhitungan tradeoff yang telah dilakukan. Anda mungkin tidak setuju dengan itu, tetapi Anda berada dalam masalah jika Anda tidak memahaminya.

Juga, pikirkan perhitungan itu dalam kurva lonceng ... beberapa orang akan membuat yang sangat buruk di kedua sisi. Lihat Duke Nukem Forever untuk salah satu ujung kurva.