Minus 2.000 Baris Kode

• Pada awal 1982, di bawah tekanan untuk merilis dalam 6 bulan, tim perangkat lunak Lisa mencoba mengukur kemajuan berdasarkan jumlah baris kode mingguan per engineer
• Bill Atkinson menilai jumlah baris tidak mencerminkan produktivitas dengan tepat, dan juga bertentangan dengan tujuan membuat program yang kecil dan cepat
• Setelah ia menulis ulang mesin perhitungan region QuickDraw dengan algoritme yang lebih sederhana dan umum, operasi region menjadi hampir 6 kali lebih cepat dan kode berkurang sekitar 2.000 baris
• Pada formulir manajemen pertama, di kolom yang menanyakan jumlah baris kode yang ditulis minggu itu, Bill menulis -2000, sehingga langsung menunjukkan kelemahan metode pengukuran tersebut
• Beberapa minggu kemudian, para manajer tidak lagi meminta Bill mengisi formulir itu, dan kisah ini menunjukkan bahwa manajemen berbasis jumlah baris kode dapat melewatkan peningkatan yang sebenarnya

---

Pengukuran jumlah baris kode di tim Lisa

• Pada awal 1982, tim perangkat lunak Lisa berusaha meningkatkan kecepatan kerja agar dapat merilis perangkat lunak dalam 6 bulan berikutnya
• Sebagian manajer mencoba melacak kemajuan berdasarkan jumlah baris kode yang ditulis setiap engineer tiap minggu
• Para engineer menerima formulir yang harus dikirim setiap Jumat, dan di dalamnya ada kolom untuk menuliskan jumlah baris kode yang ditulis minggu itu

-2000 dari Bill Atkinson

• Bill Atkinson, pembuat QuickDraw sekaligus perancang utama antarmuka pengguna, memegang peran penting dalam implementasi Lisa
• Bill menilai metrik jumlah baris kode tidak mengukur produktivitas dengan tepat
  • Ia berpendapat bahwa tujuan perangkat lunak yang baik adalah menulis program yang sekecil dan secepat mungkin
  • Metrik yang mendorong penambahan jumlah baris dapat memicu penulisan kode yang ceroboh, membengkak, dan rusak
• Saat itu ia sedang mengoptimalkan mesin perhitungan region QuickDraw
  • Ia menulis ulang sepenuhnya mesin region dengan algoritme yang lebih sederhana dan umum
  • Setelah penyesuaian, operasi region menjadi hampir 6 kali lebih cepat
  • Pada saat yang sama, kode berkurang sekitar 2.000 baris
• Saat mengisi formulir manajemen pertama, setelah sekilas melihat kolom jumlah baris kode, ia menulis -2000
• Tidak jelas bagaimana para manajer bereaksi, tetapi beberapa minggu kemudian Bill tidak lagi diminta mengirimkan formulir tersebut

[GN⁺]

Komentar Hacker News

• Ini mengingatkan pada kasus benturan jumlah baris kode antara Microsoft dan IBM
  Dalam serial TV PBS berdasarkan Accidental Empires karya Bob Cringely, ada adegan Steve Ballmer menjelaskan pengalamannya saat bersama-sama mengembangkan OS/2 dengan IBM
  Microsoft bekerja dengan pola pikir menyelesaikan pekerjaan seperti perusahaan kecil, sementara IBM dikatakan berfokus pada metrik internal, khususnya mengukur produktivitas programmer dengan KLoC (ribuan baris kode)
  Ballmer mengatakan, “Yang mereka pedulikan hanyalah KLoC, KLoC, dan KLoC lagi,” dan tampaknya IBM lebih melihat banyaknya kode daripada apakah kodenya bagus
  https://ubiquity.acm.org/article.cfm?id=1022357

  • Bukan cuma IBM. Beberapa tahun lalu saya bekerja di proyek besar dengan perusahaan konsultansi internasional besar sebagai kontraktor utama, dan saat codebase melewati 1 juta baris, mereka mengadakan pesta untuk seluruh tim
    Orang-orang yang paham situasinya menerima “perayaan” itu seperti sebuah pemakaman
  • Serial TV yang dimaksud di sini adalah Triumph of the Nerds, dan sampai sekarang pun tetap bagus. Bahkan mungkin sekarang lebih layak ditonton

• Menghitung baris kode sebagai metrik produktivitas itu benar-benar bodoh
  Saya pernah memperbaiki bug berusia 20 tahun yang tak terpecahkan dengan satu baris kode, dan saya juga ingat bug berusia 3 tahun yang selesai hanya dengan satu order by. Bagaimana mungkin dampak dari satu baris kode diukur? Dari pengalaman saya, programmer yang buruk menulis jauh lebih banyak kode
  Saya juga tidak bisa melupakan kisah tentang developer Microsoft yang menulis ulang kode IBM sepanjang 33 ribu karakter menjadi 220 karakter[1]. Akibatnya, jumlah pekerjaan Microsoft menjadi “minus” dan konon terjadilah perang
  [1] https://archive.org/details/bigbluesunmaking00carr/page/4/mode/2up halaman 101

  • Menggunakan metrik produktivitas itu sendiri pada umumnya bodoh, dan merupakan cara mudah untuk membuat developer melakukan optimasi metrik alih-alih pekerjaan yang baik
    Contoh sekarang adalah perusahaan yang menjadikan “dampak”, yaitu peluncuran produk baru, sebagai kriteria promosi. Hasilnya, sangat mudah berakhir dengan banyak produk gagal yang tidak dipelihara siapa pun
  • Memang pasti ada engineer yang sesekali memperbaiki bug kritis dan menghasilkan nilai jutaan dolar, tetapi secara umum engineer hebat memang menghasilkan banyak output, dan engineer dengan output rendah sering kali bukan engineer yang hebat
  • Dalam jangka panjang, menurut saya ada hubungan tertentu antara jumlah baris kode dan output engineering
    Di antara ilmuwan komputer dan engineer besar, ada yang menghasilkan kode dalam jumlah luar biasa, dan saya percaya itu secara langsung terhubung ke dampak dalam satu bentuk atau lainnya. Masalahnya muncul ketika jumlah baris kode dijadikan metrik untuk mengukur kinerja
    Pada saat itu, hukum Goodhart berlaku: “Saat sebuah ukuran menjadi target, itu berhenti menjadi ukuran yang baik”
  • Seperti ditunjukkan contoh-contoh ini, salah satu alasan jumlah baris kode menjadi metrik produktivitas yang buruk adalah karena metrik itu cukup baik menggambarkan besarnya beban yang harus ditanggung pemelihara codebase
    Dari sudut pandang metrik produktivitas, kode diklasifikasikan sebagai aset, tetapi sudut pandang yang lebih dekat dengan kenyataan adalah bahwa fitur adalah aset, sedangkan kode itu sendiri adalah utang

• Topik ini sering muncul. Diskusi sebelumnya sebagai berikut
  https://news.ycombinator.com/item?id=33483165 (2022)
  https://news.ycombinator.com/item?id=26387179 (2021)
  https://news.ycombinator.com/item?id=10734815 (2015)
  https://news.ycombinator.com/item?id=7516671 (2014)
  https://news.ycombinator.com/item?id=4040082 (2012)
  https://news.ycombinator.com/item?id=1114223 (2010)
  https://news.ycombinator.com/item?id=1545452 (2010)

• Di awal karier saya, saya pernah mengoptimalkan program C lebih dari 10 ribu baris yang saya warisi menjadi kurang dari 500 baris. Itu adalah program C yang melakukan pemanggilan SQL ke database Sybase
  Bukan karena saya punya wawasan luar biasa, melainkan karena asumsi sederhana bahwa pendahulu saya mungkin tidak tahu cara memakai fungsi atau cara memakai parameter untuk memasukkan data variabel ke kueri SQL. Ternyata ia benar-benar menulis pernyataan SQL yang sama berulang-ulang secara inline, hanya dengan mengganti beberapa nilai
  Saya menulis ulang kode pemanggilan SQL menjadi pemanggilan fungsi, lalu meneruskan bind variable sebagai parameter fungsi. Kode inline yang berulang diganti dengan cara mengambil nilai bind yang berubah dari array lalu memanggil fungsi di dalam loop

  • https://www.folklore.org/Discovered_Loops.html?sort=date?sort=date

• Dampak terbesar kadang datang dari melempar pertanyaan sederhana seperti “Bagaimana X akan ditangani?” sehingga sesuatu itu tidak jadi dibuat sama sekali
  Jika sesuatu itu bahkan tidak pernah punya kesempatan untuk bekerja dengan benar, berarti seluruh biaya untuk mencoba membuatnya berhasil telah dihemat
  Hal seperti ini bukan hanya mustahil diukur dengan metrik angka, tetapi juga bisa membuat orang tidak senang. Meski begitu, saya tetap memberi apresiasi kepada orang-orang yang berani melakukannya

  • Karena itu, kepada orang-orang baru saya mengajarkan agar mereka punya loop semacam itu di kepala, dan tidak langsung mulai menekan keyboard dengan cepat
    Orang yang menganggap pemrograman mirip mengetik cepat menunjukkan kemiripan yang menarik dengan LLM. Mereka menulis semua kode yang tidak akan banyak dipakai, lalu menghapusnya, lalu menulisnya lagi, lalu menghapusnya lagi
  • Saat mengelola perangkat lunak di perusahaan besar, saya menaruh kotak pensil di atas meja
    Sekitar setengah dari permintaan informasi yang masuk ke departemen selalu terdengar seperti “sangat penting, dibutuhkan sekarang juga, dan bisa menghasilkan atau menghemat banyak uang”, tetapi jawaban yang jelas adalah “Hitung saja dengan informasi yang sudah Anda miliki. Anda punya kalkulator dan spreadsheet, kan? Mau saya pinjamkan pensil?”
    Lebih baik menghindari membuat sistem menangani X daripada memaksanya menanganinya. Kasus khusus yang mungkin hanya dipakai sekali dua kali membuat sistem membengkak, dan tak seorang pun tahu apakah kasus khusus atau program seperti itu ada, atau sebenarnya melakukan apa. Bahkan jika terdokumentasi dengan baik, orang tetap tidak mau menghabiskan waktu untuk mempelajari apa yang mungkin dilakukan. Jadi sebagian besar fitur khusus seperti itu pada akhirnya hanya membuang waktu

• Sebagai eksperimen pikiran yang berpasangan, kita bisa memikirkan situasi sebaliknya. Jika seorang manajer membaca tulisan ini lalu memutuskan secara sederhana untuk mengukur berdasarkan jumlah baris kode yang dihapus, apakah hasilnya akan lebih baik atau lebih buruk?

  • Bergantung pada perusahaan dan cara pengukurannya, ini bisa lebih mudah dimanipulasi. Minta llama membuat kode yang tampak meyakinkan, tambahkan sedikit kode agar tidak memberi efek nyata, commit, lalu hapus nanti
    Jenis pengukuran seperti ini hampir tidak berguna kecuali ada praktik code review yang kuat secara menyeluruh. Berlawanan dengan apa yang ingin dipercaya banyak orang di sini, praktik seperti itu jarang ada. Tetapi jika review yang bagus memang ada, kinerja rendah maupun manipulasi metrik juga akan tertangkap, sehingga alasan untuk memperkenalkan metrik seperti ini dari awal menjadi berkurang
  • Sedikit lebih buruk, tetapi mungkin tidak seburuk yang dibayangkan. Karena di industri ini sudah ada dorongan rabun jangka pendek yang mirip ke arah itu
    Misalnya, ada gagasan lama untuk menyingkirkan software engineer dan semua teks kode yang sulit dipahami, lalu menggantinya dengan product manager yang menggambar diagram atau flowchart khusus untuk menghasilkan output “low-code” atau “no-code”
  • Semua metrik berbasis jumlah baris harus dicurigai, tetapi ΔSLOC mungkin termasuk yang tidak terlalu buruk
    Jika baris yang ditambahkan dan dihapus dihitung terpisah, patch +50,-150 akan dihitung sebagai 200 ΔSLOC
    Ini bukan ukuran yang baik untuk produktivitas, apalagi jika dipakai sendirian. Meski begitu, sebagai metrik hitung-hitungan kasar di atas kertas untuk memperkirakan besarnya perubahan, ini masuk akal. Apakah developer dengan ΔSLOC tinggi lebih produktif daripada rekan yang tidak punya ΔSLOC sama sekali selama 1–2 minggu bergantung pada apa yang sedang dikerjakan rekan itu, tetapi setidaknya jelas bahwa selama periode pengukuran orang pertama mengubah codebase lebih banyak
  • Akan lebih buruk. Menjadikan seluruh codebase sebagai sasaran code golf bukanlah hal yang diinginkan
  • Jelas tidak akan ada fitur baru
    Jika produk sudah “selesai”, hasilnya mungkin sama atau malah lebih baik. Jika tidak, perubahan baris kode negatif tidak akan sampai ke tahap deployment
    Tetapi kebanyakan produk terus berevolusi. Itulah sebabnya kita bisa tetap berada di proyek yang sama selama bertahun-tahun, dan kontribusi yang hanya menghapus pada akhirnya tidak menambahkan apa pun

• Kisah yang sebenarnya adalah bahwa saat memulai proyek, kadang kita tidak tahu persis akan menuju ke mana
  Seiring berjalan, kita memahami masalah dan jawaban yang diinginkan jauh lebih baik, lalu bisa mencabut bongkahan besar dan menggantinya dengan sesuatu yang lebih kecil dan lebih baik
  Dan kita juga tidak boleh lupa bahwa orang-orang ini harus memasukkan semuanya, termasuk kode assembly, ke dalam ROM 64KB. Tekanan untuk membuatnya lebih kecil sangat besar

  • QuickDraw sebagian besar ditulis dalam Pascal, dan hanya loop penting yang dibuat dalam assembly[1,2]
    Saya juga tidak yakin apakah itu benar-benar ada di ROM atau di floppy boot. Sebagai tambahan, menurut Wikipedia, ROM Lisa adalah 16KB
    [1] https://computerhistory.org/blog/the-lisa-apples-most-influential-failure/
    [2] https://computerhistory.org/blog/macpaint-and-quickdraw-source-code/

• Ini adalah Bill Atkinson, yang terkenal lewat Atkinson Dither. https://beyondloom.com/blog/dither.html

  • Bill Atkinson membuat QuickDraw, MacPaint, dan HyperCard—QuickDraw adalah pustaka grafis yang menjadi fondasi UI Lisa dan Mac
    Dalam prosesnya, ia terus harus menemukan cara baru agar antarmuka pengguna bisa bekerja, sekaligus cara menulis perangkat lunak untuk mewujudkannya. Ia mengoptimalkan keduanya secara bersamaan: agar “bisa berjalan cepat di perangkat keras Mac” sekaligus “memberikan pengalaman pengguna yang luar biasa”, dan sinergi itu meninggalkan jejaknya pada keseluruhan estetika Mac hitam-putih lama. Gaya dithering tersebut juga merupakan contoh lain dari perpaduan kejeniusaan algoritmik dan kepekaan estetika
    Kepekaan semacam ini juga terlihat pada hal-hal seperti bingkai seleksi “marching ants” (https://en.wikipedia.org/wiki/Marching_ants). Banyak umpan balik di UI Mac klasik juga diekspresikan lewat inversi piksel. Contohnya seleksi teks, penyorotan menu, tampilan tombol saat tombol mouse ditekan, dan garis batas saat jendela diseret; menggambar di atas dengan mode XOR adalah cara yang sangat baik untuk menciptakan efek-efek ini
    Cara QuickDraw menggabungkan alat-alat semacam ini juga membuat percakapan terkenal tentang rounded rectangle dengan Steve Jobs (https://www.folklore.org/Round_Rects_Are_Everywhere.html) benar-benar berujung pada hasil bahwa di QuickDraw, rounded rectangle bisa digambar semudah persegi panjang, dan itu membuat rounded rectangle muncul di seluruh sistem operasi
    Keberhasilan UI Mac bukan semata karena tampilannya bagus. Sebagian besar alasannya adalah karena Bill Atkinson membuat sekumpulan alat kecil yang cerdas, yang memudahkan pembuatan hal-hal yang tampak bagus
    Bahkan ikon-ikon hebat karya Susan Kare mungkin tidak akan dikenang dengan penuh kasih seperti sekarang seandainya Bill tidak membuat alat yang memudahkan memasukkan bitmap mask 32x32 piksel ke dalam UI dan membalikkannya saat diklik

• Pelajarannya adalah, sekalipun seseorang sepintar Einstein, pada akhirnya dia tetaplah karyawan, dan sebagai karyawan dia harus melakukan apa yang memang harus dikerjakan

  • Jika Einstein ditekan oleh target metrik, mungkin kita tidak akan pernah mendengar namanya

• Saya tidak pernah paham mengapa saat orang membicarakan jumlah baris kode yang ditulis, perhitungannya selalu “baris yang ditambahkan - baris yang dihapus”
  Kalau saya lari 10 km lalu kembali ke titik awal, bukan berarti saya berlari 0 km

  • Mungkin sebagian alasannya juga karena alat pembanding diff yang bodoh bisa mencatat perpindahan baris ke sana-sini sebagai perubahan besar, meskipun perubahan fungsionalnya terbatas
    Misalnya mengubah bentuk if cond { ... return; } ... menjadi if cond { ... return; } else { .... }
    Namun penjelasan itu juga tidak sepenuhnya mencakup semuanya