-2000 Baris Kode

• Pada tahun 1982, tim perangkat lunak Lisa di Apple memperkenalkan kebijakan untuk melacak jumlah baris kode mingguan tiap pengembang demi perilisan perangkat lunak
• Bill Atkinson berpendapat bahwa jumlah baris kode adalah ukuran yang keliru untuk produktivitas perangkat lunak
• Ia menulis ulang sepenuhnya mesin perhitungan region Quickdraw, mengurangi sekitar 2.000 baris kode dan meningkatkan performa 6 kali lipat
• Atkinson menuliskan -2000 pada formulir manajemen untuk laporan jumlah kode
• Pada akhirnya, manajer tidak lagi meminta Bill untuk mengumpulkan formulir tersebut

---

Tim perangkat lunak Lisa tahun 1982 dan kebijakan pelacakan jumlah baris kode

• Pada awal 1982, tim perangkat lunak Lisa mulai memusatkan upaya dengan target merilis perangkat lunak dalam 6 bulan ke depan
• Sejumlah manajer menilai bahwa melacak jumlah baris kode yang ditulis tiap insinyur setiap minggu akan membantu kemajuan
• Untuk itu, mereka memperkenalkan formulir yang harus diisi dan diserahkan setiap hari Jumat berisi jumlah baris kode yang ditulis para insinyur

Pandangan Bill Atkinson tentang tolok ukur produktivitas

• Bill Atkinson, yang merancang Quickdraw dan antarmuka pengguna, merasa bahwa jumlah baris kode tidak bisa menjadi standar produktivitas perangkat lunak
• Ia menekankan bahwa tujuannya adalah membuat program sekecil dan secepat mungkin
• Ia menyadari masalah bahwa pengukuran berdasarkan jumlah baris kode justru bisa mendorong kode yang berantakan dan tidak efisien

Refaktorisasi dan optimasi mesin region Quickdraw

• Atkinson baru-baru ini menulis ulang sepenuhnya mesin perhitungan region Quickdraw dengan algoritme yang lebih sederhana dan lebih umum
• Hasil optimasi tersebut meningkatkan kecepatan operasi region hingga 6 kali lipat
• Dalam proses ini, sekitar 2.000 baris kode juga berkurang secara alami

Laporan penulisan kode -2000 baris dan reaksi manajer

• Saat mengisi formulir manajemen minggu pertama, Atkinson menulis -2000 pada kolom jumlah baris kode
• Tidak diketahui secara pasti bagaimana para manajer bereaksi terhadap angka itu
• Beberapa minggu kemudian, Bill diminta untuk tidak lagi menyerahkan formulir tersebut, dan ia menerimanya dengan senang hati

[GN⁺]

Komentar Hacker News

• Commit terbaik yang paling saya ingat adalah saat menghapus sekitar 60 ribu baris kode, lalu mengganti seluruh “server” yang sebelumnya menyimpan semua state di memori dengan logika ringan sekitar 5 ribu baris

  • Saya menganggap ini sebagai pencapaian algoritmik yang luar biasa, karena kodenya cukup ringan untuk diintegrasikan secara alami ke layanan lain dan juga tidak memerlukan state di memori
  • Saya menemukan bahwa masalah isomorfisme subgraf terpandu pada tree tertentu bisa diselesaikan, dan berkat itu saya bisa membangun graf keluaran (tree) hanya dengan satu kali traversal pada graf ganda berarah umum, sambil melacak hanya jalur dari root awal menggunakan stack kecil
  • “Commit -60.000 baris” benar-benar momen yang tak terlupakan, dan setelah itu saya belum pernah lagi mengerjakan sesuatu yang semengesankan ini secara algoritmik, yang agak disayangkan
    • Saya ini programmer hobi yang banyak melakukan scripting di lingkungan kerja dan merasa cukup mahir di beberapa bagian pemrograman, tetapi setiap kali mendengar cerita seperti ini saya kembali merasa rendah hati karena sadar betapa luasnya dunia yang belum saya ketahui, dan bahwa belajar seumur hidup pun rasanya masih belum cukup
    • Saya ingin mendengar konteks yang lebih banyak. Teknik mengubah program yang menyimpan state menjadi stateless terasa seperti sihir, jadi saya benar-benar ingin mempelajarinya
    • Saya seorang matematikawan dengan latar belakang teori graf dan algoritma, dan saya penasaran apakah keterampilan saya bisa diterapkan pada pekerjaan nyata seperti ini. Bisa berbagi detail yang lebih spesifik?
    • Menurut saya fakta bahwa graf targetnya adalah tree tidak terlalu penting. Poin utamanya justru bahwa bagian yang “guided” itulah yang memungkinkan traversal tunggal
      • Diasumsikan bahwa jika kita memulai dari node tertentu di graf asal, maka bila isomorfisme memang ada, root pada tree target juga harus cocok dengan node tersebut
      • Masalahnya ditafsirkan sebagai menelusuri graf asal mengikuti pola tree target: jika ada ketidakcocokan maka false, jika semuanya cocok maka true. Dari sini saya menduga bahwa meskipun bukan tree, selama titik awalnya ditentukan dengan jelas, pendekatan ini bisa diterapkan ke subgraf apa pun
    • Leluconnya, mungkin nenek moyang dari soal interview coding seperti “balikkan binary tree” memang lahir dari programmer jenis seperti ini
      • Saya tertarik dengan teori graf, tetapi istilah-istilahnya terasa sulit. Bisa minta penjelasan yang lebih mudah untuk developer biasa?

• Saat kuliah saya pernah bekerja untuk sebuah perusahaan yang kebijakan manajemennya percaya bahwa mahasiswa tahun pertama bisa menulis kode yang baik, dan pada akhirnya mereka menjadi bukti kegagalan yang tak pernah mereka sadari

  • Saya pernah memperbaiki bug di kode, tetapi bug yang sama terus muncul. Setelah dianalisis, ternyata mereka berulang kali membuat salinan fungsi lama lalu sedikit memodifikasinya, alih-alih menambah parameter pada fungsi yang sudah ada. Hasilnya, saya sempat menghapus lebih dari 3/4 codebase mereka, yakni ribuan baris Turbo Pascal
  • Klien proyek itu adalah departemen Energy, dan programnya dipakai untuk mengelola inventaris material nuklir, jadi saya masih ingat malam-malam tanpa tidur karenanya
    • Secara sarkastik disebutkan bahwa keuntungan menyalin kode lama adalah stabilitas kode lama tidak terganggu, dan metrik “kontribusi” versi manajer juga tetap aman. Untuk revert pun, tinggal hapus salinannya saja
    • Di tim kami juga ada rekan yang sering membuat duplikasi kode seperti ini. Menurut saya itu kebiasaan untuk cepat menghasilkan sesuatu demi memenuhi permintaan mendesak atau orang yang paling vokal. Masalah dasarnya adalah enggan meluangkan waktu untuk refactor fungsi bersama dan menyiapkan testing yang memadai
    • Developer kontrak yang pernah saya tangani dulu juga punya kebiasaan serupa. Saat saya tunjukkan bahwa ini bisa menimbulkan kekacauan, jawabannya adalah, “Kalau begitu pakai Ctrl+F saja”
    • Ada yang penasaran apakah kasus di atas terjadi di wilayah Blacksburg
    • Pengalaman saya juga mirip. Saya pernah bekerja di perusahaan yang menjalankan portal yang hampir sama di beberapa negara Asia Tenggara. Source tiap portal disimpan di repository Git terpisah, dan setiap fitur atau perbaikan bug yang harus diterapkan ke semua portal harus di-backport manual ke banyak salinan source code, pengalaman yang benar-benar bikin tercengang
      • Saya sempat bertanya, “Kenapa tidak dimasukkan ke satu repository saja, lalu kustomisasi per portal diatur pakai feature flag?” tetapi ditolak dengan alasan itu tidak mungkin
      • Akhirnya dalam dua-tiga bulan saya menggabungkan kode 4–5 portal ke satu repository, menerapkan feature flag dan upgrade framework, lalu deployment juga selesai dengan mulus. Kini bug fix bisa dilakukan serentak ke semua portal, dan saya pun lepas dari penderitaan kerja manual yang berulang

• Sebagai topik terkait, ada yang merangkum thread Hacker News populer tentang “kode -2000 baris” seperti di tautan ini

  • Disebutkan bahwa tradisi mem-post ulang tulisan klasik secara berkala bermanfaat baik bagi pengguna baru maupun pengguna lama
    • Saya ini manusia sederhana: kalau melihat “-2k lines of code”, saya otomatis upvote
      • Kepada klien yang ingin mengelola produktivitas dengan metrik satu dimensi, saya sering menceritakan kasus Atkinson. Metrik produktivitas yang sejati seharusnya berbasis utility, dan kalau seseorang benar-benar bisa mengkuantifikasinya, menurut saya dia pantas jadi kandidat Nobel Ekonomi

• Proyek web UI yang saya tangani memiliki 250 ribu baris kode, belum termasuk backend

  • Developer sebelumnya pintar, tetapi JS adalah hal baru baginya, sehingga semua state disimpan di atribut kustom DOM dan strukturnya penuh dengan addEventListener. Saya sampai bercanda, “Kalau seorang biarawan diberi satu buku JavaScript dan 10 tahun di sel isolasi, hasilnya mungkin seperti kode ini”
  • Selama beberapa bulan saya mengubah strukturnya ke web component dan menghapus 50 ribu baris, lalu mulai menulis ulang total. Saat ini baru mencapai sekitar 80% fitur yang sama, tetapi seluruh kodenya hanya sekitar 17 ribu baris yang ringan (Vue/pinia dan library lain tidak dihitung)
  • Sebentar lagi saya akan menghapus lebih dari 200 ribu baris, dan rasanya saya tidak akan pernah lagi mengalami sesuatu yang lebih ekstrem dari ini, sampai-sampai ingin pensiun
    • Saya juga punya pengalaman serupa. Penulis aslinya kemampuannya nyaris setingkat junior, tetapi dia adalah pendiri perusahaan dan sangat produktif. Karena mengembangkan tanpa pengalaman kerja tim atau kolaborasi dengan kode orang lain, struktur itu memuat semua code smell yang bisa dibayangkan
      • Ada fungsi yang panjangnya ribuan baris, switch/case/if/else/ternary bertingkat sampai 10 level, campuran query SQL dengan JS/HTML/HTML berisi sisipan JS, dan sama sekali tidak ada automated test; benar-benar struktur frontend era PHP/Dojo
    • Ada yang menyoroti bahwa deskripsi “kode ringan dengan 80% fitur terimplementasi” sendiri menunjukkan titik lemah perbandingan seperti ini. Jika baru sebagian fitur lengkap yang diimplementasikan, tentu tidak perlu sebanyak itu baris kode seperti kode aslinya

• Ada strip komik Dilbert tentang struktur imbalan tanpa batas, di mana bos Dilbert menjanjikan hadiah uang untuk setiap bug yang diperbaiki, lalu Wally berkata, “Hari ini sepertinya aku harus meng-coding satu minivan juga!”

  • Situasi seperti ini disebut “Perverse incentive”, dijelaskan lewat tautan referensi
  • Manajer saya juga menempelkan komik ini (gambar) di dinding ruang istirahat
  • Muncul pertanyaan yang cukup praktis: sebenarnya “minivan” di sini maksudnya apa?

• Dibagikan contoh nyata penghapusan 64 ribu baris di repository dotnet/runtime

  • Dukungan interop C# + WinRT yang sebelumnya built-in diganti dengan alat source generation, sebuah perubahan struktur yang menuntut keputusan tegas untuk mengganti semuanya sekaligus. Lihat tautan PR

• Setiap kali melihat statistik tentang seberapa besar LLM meningkatkan produktivitas developer, saya teringat kisah klasik ini

  • Ada bantahan bahwa AI juga cukup bagus dalam menghapus kode, disertai contoh lucu dari komunitas terkait Cursor: “AI menghapus semuanya di komputer saya”
  • Belakangan ini, “X% dari kode baru kami ditulis oleh AI!” memang menjadi catchphrase favorit industri
  • Jika biaya membangun dan memelihara pembangkit listrik tenaga nuklir baru juga dimasukkan, statistik produktivitas developer itu jadi terasa sangat dilebih-lebihkan secara satir

• Saya bukan lulusan CS, dan bekerja dengan pengetahuan praktis yang saya pelajari sambil jalan

  • Tujuan proyek kami adalah menyusun ulang live object agar lebih mudah dibaca manusia
    • Representasi akhirnya menuntut banyak tipe yang sangat kompleks, sedangkan representasi awalnya relatif sederhana
    • Jika ada node data yang mirip, kami perlu membandingkan lalu menggabungkannya—yakni mengekstrak menjadi method dan mencari parameternya—untuk meningkatkan keterbacaan
      • Pada awalnya kami lebih dulu mengubah ke tipe akhir lalu melakukan perbandingan, sehingga kombinasi tipenya meledak dan menjadi hampir mustahil dikelola, sampai-sampai selama bertahun-tahun para engineer tidak bisa lagi memahami strukturnya
    • Belakangan saya menemukan pendekatan berbasis hashmap, lalu menerapkan struktur dua tahap: node dengan kerangka yang sama dibedakan lewat nilai hash, dibandingkan dan digabungkan, baru setelah itu dikonversi ke tipe akhir
    • Karena abstraksinya diubah dari berpusat pada tipe menjadi berpusat pada data, hierarki class yang aneh pun bisa dikelola dengan mudah sebagai properti sederhana
    • Singkatnya, ini semacam struktur decompiler bertingkat yang bodoh, tetapi pengalaman ini sangat meningkatkan kecepatan pemrosesan dan keterbacaan. Tidak ada silver bullet yang cocok untuk semua situasi, tetapi dalam kasus kami ‘tipe’ adalah masalah utamanya, dan pendekatan ini sangat membantu proyek kami

• Menjelang evaluasi kinerja akhir tahun, saya melihat statistik saya di monorepo internal perusahaan dan sadar bahwa saya menjadi orang dengan nilai bersih kode negatif

  • Itu karena penghapusan kode API dan tipe yang digenerate otomatis, serta pensiunnya API versi lama, tetapi ada rasa senang yang aneh karena setiap hari datang kerja rasanya cuma untuk menghapus kode

• Dulu sekali, di sebuah proyek besar, saya terkejut melihat contoh KPI yang menyedihkan: para PL mencatat jumlah bug per developer secara manual di atas kertas—bug yang diperbaiki dan bug yang ditimbulkan—lalu menempelkannya di dinding

  • Saya lolos dari itu karena proyek saya hanya terkait, tetapi seorang rekan, terinspirasi oleh kisah sutradara Lars von Trier yang dipulangkan setelah memotong bagian salib dari bendera Denmark dan menjahitnya kembali menjadi susunan seperti bendera komunis merah, memotong lalu menempel ulang baris jumlah bug miliknya sebagai bentuk protes terbuka terhadap “daftar penulis” versi birokrat itu. Keesokan harinya daftar tersebut lenyap untuk selamanya, dan itu menjadi kenangan berharga bagi saya
    • Jawaban sederhana dan lugas rekan itu, “Karena saya tidak ingin ada di daftar ini!” merangkum situasi ini dengan sangat baik
    • Ada juga yang berbagi kesulitan praktis untuk membayangkan seperti apa visualisasi bendera dan daftar itu sebenarnya