- Tahun 2007, 2000 Baris Kode

The Original Macintosh: 36 of 123 - 2000 Lines Of Code

• Pada awal 1982, tim perangkat lunak Lisa sedang fokus pada tahap akhir pekerjaan agar perangkat lunak dapat dirilis dalam enam bulan ke depan.

• Sebagian manajer menganggap melacak jumlah kode yang ditulis tiap insinyur setiap minggu adalah ide bagus, lalu membuat formulir yang harus diserahkan setiap hari Jumat, yang mencakup kolom untuk mengisi jumlah baris kode yang ditulis minggu itu.

• Bill Atkinson, penulis Quickdraw sekaligus perancang utama antarmuka pengguna, menganggap jumlah baris kode adalah cara bodoh untuk mengukur produktivitas perangkat lunak, karena itu hanya mendorong orang menulis kode yang berantakan, membengkak, dan penuh kesalahan.

• Atkinson baru-baru ini sedang mengoptimalkan mesin perhitungan area milik Quickdraw, dan menulis ulang sepenuhnya mesin area tersebut menggunakan algoritme yang lebih sederhana dan lebih umum, yang setelah beberapa penyesuaian membuat operasi area menjadi hampir 6 kali lebih cepat.

• Penulisan ulang ini juga menghasilkan penghematan sekitar 2000 baris kode.

• Pada tahap akhir pekerjaan optimisasi itu, tibalah saatnya untuk pertama kali mengisi formulir manajemen, dan ketika sampai di bagian jumlah baris kode, ia berpikir sejenak lalu menuliskan angka -2000.

• Tidak jelas bagaimana reaksi para manajer, tetapi beberapa minggu kemudian mereka berhenti meminta Atkinson mengisi formulir tersebut, dan ia dengan senang hati menerimanya.

Pendapat GN⁺

• Artikel ini memberi pelajaran penting bahwa jumlah kode dalam pengembangan perangkat lunak tidak mencerminkan produktivitas yang sesungguhnya. Mengukur kinerja berdasarkan jumlah baris kode bukan hanya tidak efisien, tetapi kadang juga bisa menimbulkan efek sebaliknya.
• Contoh Bill Atkinson menekankan pentingnya optimisasi perangkat lunak. Mencapai kinerja yang lebih cepat dengan kode yang lebih sedikit adalah salah satu prinsip inti rekayasa perangkat lunak.
• Kisah ini membantu memahami mengapa praktik pengembangan modern, khususnya metodologi agile dan pendekatan seperti continuous integration/deployment (CI/CD), begitu penting. Metodologi ini lebih menghargai kualitas, kemudahan pemeliharaan, dan pengalaman pengguna daripada sekadar jumlah kode.
• Di industri, berbagai alat dan metrik digunakan untuk mengukur dan meningkatkan kualitas kode. Misalnya, alat analisis kode statis, proses code review, dan pelacakan test coverage.
• Artikel ini mengingatkan para pengembang betapa pentingnya berfokus pada kualitas ketimbang kuantitas kode, menghindari kompleksitas yang tidak perlu, dan mengoptimalkan kinerja.

[GN⁺]

Komentar Hacker News

• Benturan soal jumlah baris kode antara Microsoft dan IBM

  • Dalam serial TV PBS "Accidental Empires", ada adegan ketika Steve Ballmer menjelaskan pengalamannya saat pengembangan bersama OS/2. Microsoft menangani pekerjaan dengan sikap perusahaan kecil, sementara IBM secara internal berfokus menjadikan jumlah baris kode (dalam ribuan baris, KLoC) sebagai tolok ukur produktivitas programmer. Ballmer mengkritik IBM karena hanya peduli pada kuantitas, bukan kualitas kode.

• Tautan ke diskusi-diskusi sebelumnya

  • Diskusi tentang penggunaan jumlah baris kode sebagai metrik produktivitas sering muncul. Disediakan tautan yang menunjukkan adanya berbagai pembahasan dari 2010 hingga 2022.

• Menjadikan jumlah baris kode sebagai metrik produksi adalah hal yang sangat bodoh

  • Disebutkan pengalaman memperbaiki bug berusia 20 tahun yang tak bisa diselesaikan kecuali dengan satu baris kode, atau memperbaiki bug berusia 3 tahun dengan order by, sambil mempertanyakan bagaimana dampak dari satu baris kode bisa diukur. Dibagikan pula pengalaman bahwa programmer yang buruk justru menulis lebih banyak kode, serta contoh ketika pengembang Microsoft menulis ulang 33.000 karakter kode IBM menjadi 220 karakter. Akibatnya, pekerjaan Microsoft malah dinilai "negatif".

• Pertanyaan sederhana kadang memberi dampak paling besar

  • Pertanyaan sederhana tentang bagaimana sebuah fitur akan diimplementasikan ("Bagaimana X akan ditangani?") bisa berujung pada keputusan untuk tidak membuat fitur itu sama sekali, sehingga menghemat seluruh biaya untuk mencobanya. Kontribusi seperti ini tidak bisa diukur dengan angka dan kadang bahkan bisa menimbulkan musuh, tetapi tetap patut dihormati mereka yang berani melakukannya.

• Berbagi pengalaman optimasi kode di awal karier

  • Dibagikan pengalaman mengoptimalkan program C dengan lebih dari 10.000 baris menjadi kurang dari 500 baris. Dengan asumsi sederhana bahwa pengembang sebelumnya mungkin tidak tahu cara menggunakan fungsi atau cara memberi data variabel ke kueri SQL, ditemukan bahwa pernyataan SQL yang sama ditulis inline berulang-ulang. Kode duplikat itu kemudian diganti dengan menulis ulang pemanggilan SQL ke dalam fungsi, mengambil nilai bind yang berubah dari array, dan memanggil fungsi tersebut di dalam loop.

• Kurangnya arah yang jelas saat memulai proyek

  • Saat memulai proyek, kadang kita tidak tahu persis arah yang benar. Seiring tenggelam dalam proyek, kita jadi lebih memahami masalah dan jawaban yang diinginkan, sehingga bagian besar bisa dibuang dan diganti dengan sesuatu yang lebih kecil dan lebih baik. Dalam situasi seperti ini, para pengembang yang harus memasukkan semuanya ke ROM 64KB mendapat tekanan kuat untuk membuat kode sekecil mungkin.

• Eksperimen pemikiran tentang menjadikan penghapusan kode sebagai metrik

  • Diusulkan sebuah eksperimen pemikiran: jika seorang manajer membaca artikel ini lalu secara naif memutuskan untuk memakai jumlah baris kode yang dihapus sebagai metrik, apakah keadaan akan menjadi lebih baik atau justru lebih buruk.

• Atkinson Dither karya Bill Atkinson

  • Disediakan tautan tentang Bill Atkinson dan teknik Atkinson Dither miliknya.

• Pandangan tentang jumlah baris kode

  • Dipertanyakan penggunaan 'baris yang ditambahkan - baris yang dihapus' saat menulis kode. Seperti lari 10 km yang dimulai dan berakhir di tempat yang sama tidak disebut lari 0 km, demikian pula dengan jumlah baris kode.

• Peran sebagai karyawan

  • Dibagikan pelajaran bahwa meskipun sepintar Einstein, seseorang tetaplah karyawan, dan ada hal-hal yang harus dilakukan sebagai karyawan.