Baris Kode Telah Kembali (dan Lebih Buruk Dari Sebelumnya)

Baris kode kembali digunakan sebagai metrik produktivitas, dan tim perangkat lunak di mana pun harus waspada. Apa yang dulunya didiskreditkan sebagai ukuran keluaran teknik yang sangat menyesatkan, diam-diam telah kembali muncul di ruang rapat, tinjauan kinerja, dan dasbor yang dibuat oleh AI — dan kali ini, konsekuensinya terhadap bisnis Anda jauh lebih parah.

Mengapa Baris Kode Pernah Menjadi Metrik Produktivitas?

Obsesi terhadap baris kode (LOC) dimulai pada tahun 1960an dan 1970an, ketika perangkat lunak masih baru, para manajer masih kebingungan, dan menghitung sesuatu — apa saja — terasa lebih baik daripada tidak menghitung apa pun. Jika seorang pengembang menulis lebih banyak baris, pastinya mereka melakukan lebih banyak pekerjaan, bukan?

Logikanya selalu salah. Bill Gates terkenal memperingatkan bahwa mengukur produktivitas perangkat lunak berdasarkan baris kode seperti mengukur produksi pesawat berdasarkan beratnya. Pesawat yang dua kali lebih berat tidak dua kali lebih bagus. Kode juga tidak dua kali lebih panjang.

Pada tahun 1990-an dan awal tahun 2000-an, sebagian besar industri telah mengalami kemajuan. Metodologi yang tangkas, pengukuran berbasis hasil, dan pemahaman yang semakin berkembang tentang utang teknis mendorong LOC ke dalam tong sampah ide-ide buruk. Para insinyur merayakannya. Manajer produk beradaptasi. Dunia usaha mulai mengukur apa yang sebenarnya penting: fitur yang dikirimkan, perbaikan bug, hasil yang dicapai pengguna.

Apa yang Mendorong Kembalinya Obsesi Baris Kode?

Ada dua kekuatan yang bersekongkol untuk menghidupkan kembali metrik zombie ini: alat pembuat kode AI dan tekanan eksekutif untuk bukti produktivitas yang nyata.

Ketika GitHub Copilot, Cursor, dan alat serupa membanjiri pasar, banyak perusahaan bergegas untuk membenarkan investasi AI mereka. Cara termudah untuk menunjukkan ROI? Hitung baris kode yang dihasilkan alat ini. Tiba-tiba, tim teknik menghasilkan ribuan baris per hari — dan para eksekutif mulai menganggap jumlah tersebut sebagai pencapaian utama.

Sementara itu, pekerjaan jarak jauh dan tim terdistribusi menciptakan kecemasan baru di kalangan manajer yang tidak dapat melihat pengembangnya mengetik secara fisik. Permintaan akan metrik keluaran yang dapat diukur melonjak. LOC menawarkan ilusi visibilitas. Rasanya objektif. Rasanya terukur. Rasanya aman.

Ini bukanlah hal-hal tersebut.

Mengapa Kembalinya Masalah Lebih Buruk dari Masalah Aslinya?

Ketika pengembang manusia menulis kode berlebihan untuk meningkatkan jumlah LOC mereka, kerusakan yang ditimbulkan dibatasi oleh kecepatan manusia. Seorang pengembang hanya bisa mengetik begitu cepat, menciptakan begitu banyak fungsi yang berlebihan, atau memasukkan begitu banyak blok komentar dalam satu hari kerja.

AI mengubah segalanya. Seorang pengembang dengan asisten AI kini dapat menghasilkan puluhan ribu baris dalam hitungan jam. Jika tinjauan kinerja mereka menghargai volume, mereka memiliki insentif untuk membiarkan AI menjadi liar – menghasilkan kode yang bertele-tele, membengkak, dan tidak dapat dikelola yang terlihat mengesankan dalam spreadsheet dan merupakan bencana besar dalam produksi.

"Metrik yang paling berbahaya adalah metrik yang mudah untuk ditiru. Jika imbalannya berupa baris kode, hasilnya bukan produktivitas yang lebih tinggi, melainkan lebih banyak kode. Itu adalah hal yang sangat berbeda."

Dampak hilirnya sangat parah dan semakin parah. Basis kode yang membengkak lebih sulit untuk di-debug, lebih lambat untuk diterapkan, lebih mahal untuk dipelihara, dan jauh lebih rentan terhadap eksploitasi keamanan. Setiap baris kode yang tidak perlu adalah kewajiban masa depan yang ada di neraca Anda, tidak terlihat sampai merusak sesuatu yang penting.

Apa yang Sebenarnya Harus Diukur oleh Bisnis Modern?

Kabar baiknya adalah terdapat alternatif yang lebih baik dan telah teruji oleh organisasi teknik berkinerja tinggi. Jika bisnis Anda saat ini melacak LOC dalam kapasitas apa pun, segera ganti dengan metrik yang benar-benar berkorelasi dengan hasil bisnis:

Frekuensi penerapan: Seberapa sering tim Anda mengirimkan perangkat lunak yang berfungsi ke produksi? Tim berkinerja tinggi dikerahkan beberapa kali per hari, bukan per kuartal.

Waktu tunggu untuk perubahan: Berapa lama waktu yang dibutuhkan dari perubahan kode yang dilakukan hingga perubahan tersebut berjalan dalam produksi? Lebih pendek lebih baik — artinya proses Anda ramping dan responsif.

Ubah tingkat kegagalan: Berapa persentase penerapan

Related Posts

• CXMT telah menawarkan chip DDR4 dengan harga sekitar setengah dari harga pasar yang berlaku
• Saya memberi Claude akses ke plotter pena saya
• Apa yang harus diketahui oleh setiap penulis kompiler tentang programmer (2015) [pdf]
• FDA mengatakan perusahaan dapat mengklaim "tidak ada pewarna buatan" jika mereka menggunakan pewarna alami