Terdapat kesenjangan mengejutkan dalam penelitian pengembangan perangkat lunak: tidak ada yang tahu berapa banyak waktu yang sebenarnya dihabiskan developer untuk menulis kode guna mendeteksi dan menangani error dibandingkan dengan membangun fitur inti. Fakta ini terungkap ketika seorang peneliti yang bekerja pada tools toleransi kesalahan mencari data untuk mendukung klaim produktivitas mereka, namun menemukan bahwa pengukuran yang dapat diandalkan ternyata tidak ada.
Satu-satunya angka konkret yang tersedia berasal dari buku tahun 1995 oleh Dr. Flaviu Cristian , yang memperkirakan bahwa penanganan error sering kali menyumbang lebih dari dua pertiga kode dalam sistem produksi. Hampir tiga dekade kemudian, ini tetap menjadi satu-satunya titik referensi kuantitatif dalam industri yang telah menjadi semakin kompleks dan terdistribusi.
Statistik Kunci dari Penelitian yang Tersedia:
- Penanganan error menyumbang lebih dari dua pertiga kode dalam sistem produksi (studi 1995 oleh Dr. Flaviu Cristian)
- Developer menghabiskan sekitar 11% waktu mereka untuk debugging dan perbaikan bug secara rata-rata
- Beberapa hari bisa mencapai hingga 32% waktu yang didedikasikan untuk tugas debugging
- Aktivitas testing dapat mengonsumsi hingga 16% waktu developer
- Perusahaan-perusahaan mengklaim kerugian $2 triliun USD akibat bug pada tahun 2020
Perusahaan Menghindari Mengukur Apa yang Tidak Ingin Mereka Danai
Kurangnya data ini tidak sepenuhnya kebetulan. Banyak perusahaan sengaja menghindari pelacakan waktu yang dihabiskan untuk penguatan karena tidak berkontribusi langsung pada pengembangan fitur atau generasi pendapatan. Hal ini menciptakan blind spot di mana pekerjaan penting namun tidak glamor menjadi tidak terukur dan tidak dihargai.
Beberapa organisasi memang melacak waktu perbaikan bug untuk tujuan pelaporan keuangan, membedakan antara biaya operasional (memperbaiki bug) dan biaya modal (membangun fitur). Namun, pendekatan yang didorong akuntansi ini hanya menangkap debugging reaktif, bukan penanganan error proaktif yang terjadi selama pengembangan awal.
Tantangan Pengukuran Melampaui Pelacakan Sederhana
Bahkan ketika perusahaan ingin mengukur upaya penguatan, tugas ini terbukti sangat kompleks. Pekerjaan penanganan error sering terjadi bersamaan dengan aktivitas pengembangan lainnya. Seorang developer mungkin memicu load test, mengerjakan fitur lain saat test berjalan, kemudian kembali untuk menganalisis hasil dan memperbaiki masalah. Alur kerja yang saling terkait ini membuat pelacakan waktu yang tepat menjadi sulit tanpa menambahkan overhead yang signifikan.
Masalah ini melampaui sekadar logistik pengukuran. Pendekatan pemrograman yang berbeda secara fundamental mengubah cara waktu penanganan error didistribusikan. Dengan result types, developer harus mempertimbangkan skenario kegagalan di setiap langkah, yang mengarah pada pengembangan awal yang lebih lama namun kode yang lebih robust. Dengan sistem berbasis exception, developer dapat fokus pada happy path awalnya, kemudian menangani error saat muncul selama testing.
Pendekatan Penanganan Error yang Berbeda:
- Result Types: Memerlukan pertimbangan kegagalan di setiap langkah, pengembangan awal lebih lama tetapi kode lebih robust
- Exception-Based: Fokus pada jalur yang bahagia terlebih dahulu, menangani error saat muncul selama pengujian
- Faktor Trade-off: Biaya kegagalan, kesulitan pemeliharaan di masa depan, kemudahan dalam menerapkan perbaikan
Industri Memprioritaskan Kecepatan Daripada Ketahanan
Dinamika pasar saat ini sangat mendukung pengembangan fitur yang cepat daripada penguatan perangkat lunak. Dalam lingkungan yang didorong venture capital, perusahaan sering memilih untuk menskala infrastruktur daripada mengoptimalkan kode, menambahkan mekanisme retry sederhana alih-alih mengimplementasikan toleransi kesalahan yang tepat, dan mengandalkan bug bounties daripada berinvestasi dalam keamanan dari awal.
Waktu yang dihabiskan untuk penguatan perangkat lunak selalu nol atau sangat mendekati itu kecuali perusahaan menjadikan penguatan tersebut sebagai selling point dari produk yang mereka buat.
Pendekatan ini menciptakan technical debt yang menjadi mahal untuk ditangani kemudian. Ketika masalah muncul dalam produksi, biaya memperbaikinya jauh melebihi apa yang diperlukan penguatan proaktif. Namun orang-orang yang membuat keputusan jangka pendek ini jarang menghadapi akuntabilitas untuk konsekuensi jangka panjang.
Penelitian Berfokus pada Masalah Akademis Sambil Mengabaikan Pertanyaan Praktis
Tidak adanya metrik industri dasar menyoroti masalah yang lebih luas dalam penelitian rekayasa perangkat lunak. Sementara peneliti semakin menerapkan large language models pada masalah buatan dan mengklaim peningkatan incremental atas baseline yang arbitrary, pertanyaan fundamental tentang bagaimana developer sebenarnya menghabiskan waktu mereka tetap tidak terjawab.
Kesenjangan pengetahuan ini memiliki konsekuensi nyata. Tanpa data yang dapat diandalkan tentang overhead penanganan error, tidak mungkin untuk mengevaluasi dengan tepat tools yang mengklaim meningkatkan produktivitas developer dengan mengurangi beban ini. Perusahaan tidak dapat membuat keputusan yang tepat tentang investasi dalam infrastruktur toleransi kesalahan, dan industri terus beroperasi berdasarkan asumsi daripada bukti.
Situasi ini mengungkapkan bagaimana industri yang dibangun atas data dan pengukuran memiliki blind spot yang mengejutkan tentang praktik mereka sendiri. Sampai kesenjangan ini ditangani, pengembangan perangkat lunak akan terus dipandu lebih oleh intuisi dan tekanan pasar daripada oleh pemahaman yang solid tentang di mana waktu dan upaya sebenarnya dihabiskan.
Referensi: Time Spent on Hardening