Butuh 6 Hari untuk Mengubah Satu Baris Kode (2015)

• Ketika tingkat utilisasi pabrik turun 10%, perusahaan mencoba menumpuk persediaan sebelum musim ramai alih-alih melakukan PHK, dan untuk itu dimulailah permintaan mengubah batas backlog 3 bulan menjadi 4 bulan
• Penanggung jawab TI menilai cukup mengubah satu nilai hardcoded di rutinitas inti, tetapi terlebih dahulu perlu membuat tiket, menuliskan dampak bisnis, mendapat persetujuan, dan menyesuaikan prioritas antrean
• Programmer mengubah nilai MonthsOfBacklog dari "3" menjadi "4" pada baris 1252 di Module ORP572 dan lolos pengujian, tetapi dalam code review bahkan pelanggaran kebijakan yang sudah ada ikut menjadi sasaran perbaikan
• Cakupan perubahan meluas ke prosedur tambahan seperti menjadikannya record di file Parameters, menghapus perintah debug, peringatan variabel yang belum diinisialisasi, Employee ID yang di-hardcode, hak akses, lingkungan pengujian, rencana pengujian, dan tanda tangan pengguna
• Perubahan yang dibutuhkan untuk pekerjaan sebenarnya hanyalah 1 baris·1 byte, tetapi total waktu yang berlalu adalah 6 hari, dan prosedur serta kebijakan internal sangat memperpanjang lead time nyata untuk perubahan kecil

---

Permintaan untuk mengubah batas 3 bulan menjadi 4 bulan

• Presiden Philip mengatakan pabrik sedang dalam kondisi 10% menganggur, dan ia ingin memproduksi backlog lebih banyak untuk menumpuk persediaan sebelum musim ramai daripada melakukan PHK
• Manajer operasi Lee mengatakan bahwa menurut kebijakan perusahaan hanya boleh membuat backlog hingga 3 bulan, jadi jika batasnya diubah menjadi 4 bulan maka akan ada cukup pekerjaan
• Penanggung jawab TI David menilai sepertinya cukup mengubah satu baris kode di rutinitas inti perangkat lunak legacy, lalu meminta agar tiket diajukan ke IT Services
• Manajer TI Judy menetapkan permintaan itu sebagai Ticket# 129281, tetapi mengatakan bagian Business Impact dan persetujuan Director diperlukan
  • Ketika David menyebut kemungkinan PHK, Judy langsung mengisi bagian tersebut dan menaikkannya untuk diproses cepat
  • Bahkan 2 hari kemudian, permintaan itu masih berada di antrean Developer Queue sebagai Enhancement pertama di belakang 14 Bug Report
  • David menandai permintaan itu sebagai mendesak dan memerintahkan agar segera dikirim ke Ed

Bagaimana perubahan satu baris membesar menjadi perubahan prosedur

• Ed mengubah variabel hardcoded MonthsOfBacklog dari "3" menjadi "4" pada Module ORP572 baris 1252
  • Lolos unit test dan menjalankan batch test 2 kali
  • Antrean kerja Operations meningkat 10% seperti yang diperkirakan
  • Perubahan itu diteruskan ke Code Review dan User Acceptance Testing oleh Homer
• Peninjau kode Shirley menuntut agar variabel hardcoded itu dijadikan record di file Parameters karena bertentangan dengan kebijakan perusahaan
  • Ia juga mengatakan 2 perintah Debug yang sudah ada, peringatan variabel yang belum diinisialisasi, dan Employee ID yang di-hardcode harus diperbaiki sebelum masuk produksi
  • Karena Ed ditugaskan ke ORP572, menurutnya Ed juga harus bertanggung jawab atas error lama yang melanggar kebijakan perusahaan baru
• Lingkungan pengujian juga menjadi faktor keterlambatan
  • Homer tidak bisa dipakai karena control test untuk penutupan akuntansi akhir bulan, jadi harus memakai Marge
  • Ed tidak punya hak akses ke Marge, dan Joe dari IT Security mengatakan hak itu tidak bisa diberikan tanpa tanda tangan David
• Pekerjaan record Parameters meluas karena tuntutan tambahan
  • Nama MonthsOfDemand dianggap perlu diganti dengan nama yang lebih baik karena programmer luar negeri akan sulit memahaminya
  • Record Parameter baru harus memiliki audit trail, tetapi kebijakan itu tidak terdokumentasi dan pembaruan wiki pun tertunda 3 bulan
  • Ed mengganti namanya menjadi SelectedMonthsOfBacklogDemand, lalu menambahkan Module PAR634 yang menyimpan record tersebut beserta audit trail-nya
• Penguji Tony menunjukkan bahwa 129281 terlihat di Marge tetapi tidak ada Test Plan
  • Ed mengatakan cukup menjalankan cara lama dan cara baru lalu memastikan total laporan WorkOrdersHours meningkat, tetapi Tony menuntut Test Cases pilihan pengguna, Expected Results, Test Runs yang terdokumentasi, dan sign-off pengguna karena ini memengaruhi seluruh pabrik
  • Dua hari kemudian, Philip memerintahkan David agar menyuruh Tony segera memindahkan program Ed ke produksi
• Total waktu yang berlalu adalah 6 hari, dan perubahan pada mission critical code hanyalah 1 baris·1 byte
  • Excedrin yang dikonsumsi: 24 tablet
  • Waktu jengkel yang dihabiskan di Hacker News tercatat 14 jam

[GN⁺]

Komentar Hacker News

• Intinya ada pada reviewer yang menuntut, “kalau mau mengubah ini, masalah lain yang belum terselesaikan di codebase juga harus diperbaiki sekaligus.”
  Dalam situasi seperti ini, kita perlu mendorong balik dengan mengatakan, “Arah untuk meningkatkan kualitas kode memang bagus, tetapi jika mengubah Y, perlu persetujuan X/Y/Z dan akan memakan beberapa hari lagi. Mari jadikan hal yang Anda sebutkan sebagai pekerjaan utang teknis, lalu menanganinya di PR lanjutan sesuai prioritas dan kapasitas. Untuk saat ini, mari fokus pada apa yang diperlukan agar PR lokal yang terbatas ini bisa dideploy.”
  Pelajaran terbesar adalah membuat PR yang terfokus, dan belajar membantah ketika reviewer mencoba memperluas cakupan. Pada umumnya engineer lain menerimanya secara pragmatis. Ini tidak ada hubungannya dengan jumlah baris. Bisa saja seluruh kode hanya diformat ulang tanpa perubahan logika, atau beberapa feature flag saja diubah tetapi dampaknya besar. Harus hanya ada satu perubahan terfokus dalam satu waktu

  • Saya tidak setuju bahwa “kalau mau mengubah ini, masalah lain yang belum terselesaikan juga harus diperbaiki” adalah intinya. Hal terburuk di sini adalah butuh 6 hari untuk mengubah satu baris kode, dan hampir separuh dari waktu itu berlalu sebelum engineer melihat isu tersebut
    Jika ini prioritas setinggi itu sampai perusahaan harus melakukan pemecatan bila tidak segera ditangani, maka 2–3 hari sebelum ada orang yang melihatnya sama sekali tidak boleh terjadi. Namun dalam proses pengembangan ini, tampaknya itulah “jalur cepat”-nya
    Dua hari terakhir juga terlihat seperti tidak terjadi apa-apa karena rencana pengujian dinilai tidak memadai. “Kalau mau mengubah ini, masalah lain yang belum terselesaikan juga harus diperbaiki” hanya memakan 2 jam di sini, dan bahkan sebelum melihat bagian itu pun setidaknya ada 2–3 hal lain yang bisa ditunjuk sebagai masalah inti proses ini
  • Biasanya saya menghindari perbaikan yang tidak langsung terkait dengan tugas yang sedang dikerjakan. Sekadar menambahkan satu titik koma yang hilang pun bisa menarik perhatian reviewer yang terlalu antusias dan menyeret kita ke lubang kelinci perbaikan legacy
    Daripada meninggalkan FIXME atau TODO, saya cenderung diam-diam membuat issue agar tidak lupa. Bagian review seperti ini sudah rusak. Pelunasan utang teknis harus direncanakan secara terpisah, bukan menjadi syarat penyelesaian pekerjaan
  • Orang-orang yang melakukan perluasan cakupan tidak menyadari kerusakan arsitektur yang mereka sebabkan. Jika terlalu terobsesi pada satu blok kode, orang-orang akan mencoba memutar melewati area itu
    Jika lapisan seperti itu menumpuk, pada akhirnya kode menjadi setara secara moral dengan Atlanta, GA, yang terkenal karena banyaknya jalan lingkar
  • Menurut saya solusi yang lebih baik adalah mengotomatiskan aturan
    Ketika aturan baru ditambahkan, otomatisasi harus memberi komentar pengecualian aturan pada semua titik pelanggaran yang sudah ada, dan membuatnya bisa dilacak. Jika kode yang harus segera dideploy perlu melanggar aturan, tambahkan komentar pengecualian dan cantumkan nama sendiri sebagai penanggung jawab untuk memperbaikinya nanti
    Seiring waktu, kita bisa membangun budaya memperbaiki pelanggaran aturan seperti ini secara terpisah dari pengembangan fitur
  • Jika hal seperti itu terjadi, cukup tambahkan tiket TODO. Pemblokiran produksi dilepas, dan sistem juga tidak menjadi lebih buruk

• Benar. Proses code review di sebagian besar perusahaan penuh dengan mencari-cari kesalahan dan komentar sepele
  Dulu saya pernah mengusulkan agar komentar seperti ini dihapus dan diganti dengan alat analisis statis supaya feedback lebih cepat, tetapi jawabannya adalah code review semacam itu diperlukan oleh semua orang. Karena itu membantu orang dipromosikan, memberi perasaan bahwa mereka mencegah masalah kode, dan membuat metrik code review terlihat bagus bagi manajer tingkat atas saat mereka melihat jumlah komentar reviewer

  • Saya tidak suka penggunaan alat seperti ini secara berlebihan. Tidak jarang kode justru menjadi lebih buruk demi memuaskan alat yang bodoh
    Solusi sebenarnya adalah menerima bahwa semua kode tidak perlu terlihat seolah-olah saya yang menulisnya sendiri, dan bertanya pada diri sendiri, “Apakah komentar ini membahas kesalahan objektif dalam kode?” Dalam banyak kasus jawabannya adalah “tidak”
  • Di sini kadang ada dilema tahanan yang nyata. Ketika seorang senior mereview PR junior, sering ada bagian yang bisa dibuat lebih baik tetapi tidak penting
    Jika hanya nama variabel yang agak terlalu panjang atau jarak antar-metode yang tidak konsisten, idealnya itu cukup menjadi “feedback untuk diingat lain kali jika ini menjadi pola.” Namun dari sisi reviewer, mereka bisa melihat jumlah komentar per PR sebagai metrik seberapa banyak mereka membimbing, atau khawatir akan reaksi “siapa yang membiarkan itu dimerge?”, sehingga akhirnya mereka meninggalkan komentar
    Orang yang direview kemudian memperbaikinya karena takut terlihat kurang responsif terhadap feedback bila tidak menanganinya, atau takut reviewer memberi penilaian buruk jika membantah. Lalu versi yang diperbarui harus disetujui lagi, dan siklus penundaan dimulai kembali
  • Dalam lingkungan tertentu, itu benar. Namun proses review juga membantu membangun pengetahuan bersama dan pemahaman tentang perubahan serta codebase
  • Mencari-cari kesalahan jelas benar-benar ada. Mungkin karena ada perasaan bahwa kita harus menemukan sesuatu yang salah dalam kode
    Namun ada juga masalah yang oleh sebagian orang dianggap sebagai nitpick, padahal sebenarnya sama sekali bukan hal sepele. Bisa jadi karena mereka tidak melihat masalahnya dengan mata sendiri, tidak memahami masalahnya, atau kurang mampu melepaskan emosi dan memikirkan ulang kode yang mereka tulis
    Kita semua pernah merasa melekat pada kode yang kita tulis, dan mungkin menganggapnya sebagai kode paling elegan di dunia. Namun terkadang kita harus mengakui bahwa kita salah, bahwa kode itu sulit dibaca atau cacat, dan merugikan codebase
    Saya pernah menunjukkan race condition yang bisa menjadi masalah nyata dalam kode orang yang lebih senior dari saya, lalu disebut tukang cari-cari kesalahan. Bagi saya, race condition adalah masalah mendasar pada kode yang ditulis dan harus diperbaiki, tetapi bagi orang itu, karena ia belum pernah melihatnya rusak secara alami, kondisi tersebut masih bisa diterima
  • Alat analisis statis dan peer review bisa menangkap jenis masalah yang berbeda. Sama seperti bahasa terkompilasi statis dapat menangkap sebagian bug yang tidak bisa ditangkap bahasa dinamis, tetapi tidak semuanya
    Saya sangat menyukai peer review, dan biasanya berfokus pada “kode ini tidak akan berjalan seperti yang diharapkan”, “cara ini akan menghambat implementasi atau membuatnya jauh lebih mahal”, “ini berjalan, tetapi sulit dipahami sehingga berdampak buruk pada pemeliharaan; pertimbangkan cara lain atau tambahkan penjelasan”, serta “kodenya baik-baik saja, tetapi bisa dibaca atau berjalan lebih baik. Ini tidak membuat review gagal, tetapi layak diingat untuk kode berikutnya”

• “Julie: Hubungi Joe dari tim keamanan IT. Dia akan memberi izin. 2 jam kemudian.” itu sama sekali tidak realistis. Tim keamanan tidak mungkin merespons secepat itu

  • Kecuali kalau kamu menjalankan “npm install” lalu muncul peringatan keamanan P1
  • Tim keamanan kami sebenarnya merespons lebih cepat. Mereka otomatis menolak semua permintaan, tetapi menolaknya seketika
  • Di tempat saya bekerja, pengalamannya sangat berbeda. Kalau kita membuat tiket untuk meminta akses seseorang ke sistem tertentu, biasanya diproses dalam beberapa menit, apa pun prioritasnya
    Kadang saya bertanya-tanya apakah staf helpdesk langsung menyambar tiket begitu masuk karena itu tiket yang bisa cepat ditutup dan bagus untuk metrik pribadi mereka
  • Menambahkan seseorang ke grup AD yang diperlukan untuk hak edit wiki bisa memakan waktu berminggu-minggu

• Kalau dikatakan seperti judulnya, butuh 6 hari untuk mengubah satu baris kode, memang terdengar mengerikan
  Namun sistemnya membaik dalam beberapa hal. Konfigurasi menjadi dapat diatur lewat tabel parameter alih-alih di-hardcode, dan ada juga fungsi audit untuk melacak perubahan konfigurasi itu
  Saya tidak bermaksud membela birokrasi. Saya benar-benar tidak suka sisi seperti itu dari organisasi besar. Saya hanya ingin menunjukkan bahwa selain tujuan awal, ada nilai tambahan yang tercipta selama 6 hari itu
  Jadi estimasi harus memasukkan sejumlah biaya sampingan, dan kalau memakai story point, biaya prosedural seperti ini juga harus diperhitungkan

  • Satu-satunya alasan tabel parameter itu berguna adalah karena ada terlalu banyak hal yang menghalangi perubahan kode. Demikian pula, audit untuk konfigurasi ini tampaknya tidak perlu. Dulu nilainya ada di kode, jadi source control sudah menjadi jejak audit
    Pada akhirnya, dua hasilnya adalah “pencapaian” berupa menghindari ritual tambahan di sekitar perubahan kode, dan “pencapaian” berupa mendapatkan kembali fungsi yang hilang akibat “pencapaian” pertama karena ke depannya perubahan ini tidak lagi masuk ke kode
  • Benar, tetapi mereka juga melakukan sesuatu yang bisa jauh lebih berisiko daripada permintaan awal. Dalam situasi ada gangguan langsung atau masalah produksi nyata, mendorong nilai hardcoded menjadi parameter menurut saya bodoh. Potensi jebakannya jauh lebih banyak
    Seharusnya mereka berkata, “Ini mendesak, jadi tolong terima PR satu karakter ini. Perbaikan yang Anda minta sudah saya buatkan tiket untuk dilacak. Kita selesaikan dulu masalah produksi, sisanya menyusul”
    Reviewer tinggal bilang “LGTM!” Kalau kebanyakan engineer tidak bisa menavigasi antara aturan dan panduan, organisasi itu sudah gila, dan justru di titik seperti inilah senioritas bernilai
  • Langkah pertama adalah menilai prioritas sebenarnya. Semua orang harus tahu seberapa lama penundaan pekerjaan ini sebelum berdampak pada pekerjaan orang-orang
    Kalau butuh seminggu pun tidak berdampak pada pekerjaan siapa pun, ikuti proses atau ubah seminimal mungkin. Kalau orang-orang dirumahkan tanpa gaji gara-gara IT, semua orang yang diperlukan harus berada di ruangan yang sama, fisik ataupun virtual, sampai masalahnya selesai
    Konteks itu tidak ada di sini. Namun kalau Ed dan seluruh jalur persetujuan tidak mengetahui konteks itu, itu adalah kegagalan sistem. Kalau mereka tahu ada uang sewa seseorang yang dipertaruhkan, orang senior mungkin akan langsung mengusulkan membuat tiket kedua untuk memperbaikinya setelah ini. Kalau tidak, itu juga masalah yang harus diselesaikan manajemen
  • “Butuh 6 hari untuk mengubah satu baris kode” hanyalah pernyataan fakta. Bagian bahwa sistem membaik selama proses itu bukanlah persyaratan wajib
  • Persyaratan audit sepertinya bisa dipenuhi dengan riwayat versi dari file yang berisi nilai hardcoded itu. Kalau mereka tidak memakai version control, berarti ada masalah lain yang lebih besar

• Cerita ini adalah kasus ketika perubahan satu baris pada nilai hardcoded sebenarnya berjalan baik
  Bisa dibayangkan skenario ketika seseorang menyimpan jumlah bulan backlog sebagai nilai 2-bit supaya terlihat pintar dan cerdik. Hanya 0, 1, 2, 3 yang mungkin. Saat pengujian, masalahnya bisa tidak terlihat karena tersembunyi beberapa lapisan di bawah, di sub-layanan yang tidak diuji atau layanan otomatisasi low-code
  Kalau nilainya diubah menjadi 4, backlog bisa menjadi 0. Tidak ada yang tahu hasilnya. Layanan itu bisa saja membatalkan semua pekerjaan di antrean produksi, atau mengirim email kepada pelanggan bahwa pekerjaan mereka dibatalkan
  Dari luar tampak seperti perubahan mudah, tetapi kalau perubahan kebijakan diteruskan ke tim software sebagai masalah mendesak, manajemen seharusnya merencanakan lebih baik, bukan mengguncang prioritas isu secara sewenang-wenang

  • Tidak ada bagian dari perubahan yang diminta yang terkait dengan pengujian tambahan atau pengurangan risiko
    Justru, sebagai “biaya” perubahan, mereka diminta melakukan refactor pada beberapa bagian di sekitarnya, sehingga risikonya meningkat
  • Ada banyak sekali cara hal ini bisa salah. Pertanyaan sebenarnya mungkin adalah ke mana tanggung jawabnya mengalir saat terjadi kesalahan
    Akan bagus kalau bos besar berkata, “Saya memutuskan untuk mengambil risiko dan mendorong ini, dan saya menerima konsekuensinya.” Tidak bagus kalau para programmer yang kena
  • Menurut saya mereka memang mengikuti orang dan proses yang tepat. Hanya saja, kalau para lead dikumpulkan untuk rapat dan menyelaraskan pentingnya serta prioritas pekerjaan ini, banyak waktu bisa dihemat
    Jika ini pembaruan penting dan sensitif terhadap waktu untuk fungsi inti, penanggung jawab operasional seharusnya mengetahui waktu deployment rata-rata software tersebut, dan seharusnya membentuk tim untuk penanganan cepat alih-alih memasukkannya sebagai prioritas tinggi ke pipeline pengembangan biasa
  • Saya jadi teringat Knight Capital

• Code review bermula dari niat baik. Namun pada akhirnya ada penjaga gerbang yang mengambil posisi dan mulai menolak semuanya karena alasan sepele
  Mereka bilang peduli menjaga “kualitas kode”. Namun tidak ada yang lebih buruk daripada membiarkan kode bug yang perbaikannya sudah siap tetap lama di sana, atau menunda fitur sampai tidak ada yang bisa mencobanya
  Saya merekomendasikan proses yang mengizinkan komentar, tetapi reviewer tidak bisa memblokir commit. Kita harus percaya bahwa tiap developer akan berhati-hati dan membuat perubahan yang sesuai dengan pekerjaannya. CI juga bisa dipakai, dan tergantung timnya, semuanya bisa berjalan cukup baik

  • Kalau begitu pemimpin engineering harus menghentikan orang itu. Disfungsi muncul dalam banyak bentuk, dan review yang terlalu bersemangat adalah salah satunya
    Mengubah proses agar reviewer patologis bisa diabaikan paling banter hanya solusi setengah hati
    Saya ambivalen soal pemblokiran. Saya paham bahwa tanda blokir merah besar itu membuat frustrasi, jadi dalam banyak kasus saya melakukan “soft block”, meminta perubahan tanpa memblokir. Namun ketika PR benar-benar melenceng, biasanya pada developer junior, saya rasa menyampaikan pesan yang jelas itu tepat
  • Cara ini bekerja dengan baik ketika cakupan pengujian dan kualitas pengujian tinggi. Itu pun tidak akan muncul secara ajaib hanya karena developer dibiarkan bergerak secepat yang menurut manajer diperlukan saat ini
  • Saya benci aturan “setiap perubahan kode membutuhkan reviewer”. Itu gangguan besar, dan tidak selalu menghasilkan kode yang lebih baik

• Ini adalah cerita meta tentang pekerja pabrik dan pengembang perangkat lunak
  Pemimpin perusahaan ini bersedia memecat pekerja pabrik karena utilisasi kurang 10%. Beberapa variabel bisa disesuaikan untuk meningkatkan produktivitas, tetapi pada akhirnya pilihannya adalah utilisasi penuh atau menganggur. Mungkin ini dimungkinkan karena para pekerja ini dapat digantikan dan bisa direkrut kembali pada musim ramai, serta laba yang dihasilkan per karyawan tidak memungkinkan adanya inefisiensi
  Saya bekerja sebagai pengembang perangkat lunak. Di bidang kami, orang baru mulai berpikir untuk melepas seseorang kalau underutilization jauh melampaui 90%. Banyak orang hanya bekerja 4 jam seminggu. Tidak ada yang mengelola waktu kami per menit, jeda ke toilet, dan sebagainya
  Saat ini adalah masa kapitalisasi besar-besaran untuk perangkat lunak. Ini tidak akan berlangsung selamanya. Suatu hari nanti, infrastruktur utama dunia IT akan selesai dibangun dan industri akan beralih ke mode pemeliharaan. Sebagian besar dari kita tidak lagi dibutuhkan, akan menjadi mudah digantikan, dan laba yang kita hasilkan dalam mode pemeliharaan akan remeh dibandingkan dengan yang terlihat sekarang
  Pekerja pabrik biasanya dipecat dalam hitungan menit atau jam ketika produktivitas individunya terdeteksi rendah. Saya rasa hal seperti ini juga akan mulai terjadi pada pengembang perangkat lunak dalam masa hidup kita

  • “Para pekerja ini dapat digantikan dan bisa direkrut kembali pada musim ramai” adalah tepatnya perbedaannya. Pabrik adalah sistem proses yang dirancang untuk menghilangkan pengambilan keputusan dan variabilitas dari setiap orang
    Anda juga perlu menilai sejauh mana hal itu mungkin untuk kumpulan keahlian Anda sendiri
    Saya setuju dengan poin dasarnya bahwa kapitalisasi besar-besaran perangkat lunak tidak akan berlangsung selamanya. Tidak semua perusahaan akan selalu membutuhkan engineer untuk mengembangkan perangkat lunak baru. Ini lebih mirip bisnis kreatif dengan masa boom dan bust, seperti produksi film. Jika Anda memilih development ketimbang IT, Anda harus menerima risiko itu. Namun saya tidak tahu kenapa sekarang harus menjadi puncaknya

• Dari pengalaman pribadi, setelah beberapa tahun bekerja di tim yang memiliki code review formal, saya pindah ke tim/perusahaan tanpa code review. Siapa pun bebas commit dan merge ke branch mana pun
  Saat bergabung, perasaan saya agak campur aduk, tetapi dalam praktiknya ini terasa sangat menyegarkan dan memberi rasa diberdayakan, sehingga dalam beberapa hari saya sudah bisa bekerja produktif

  • Dulu saya pernah bekerja di tim yang melakukan “code review Katolik”, yaitu push and pray
    Mengingat tujuan tim, pendekatan tanpa code review sangat cocok. Sebab ini adalah grup riset dan pengembangan yang tujuan utamanya mendemokan “fitur baru yang keren” kepada para eksekutif. Banyak permintaan datang dengan pemberitahuan singkat, tetapi banyak juga kode yang dibuang
    Setelah demo, eksekutif akan berkata “kelihatannya bagus, tapi tidak ada nilai bisnisnya,” lalu repositori itu tidak pernah disentuh lagi. Tentu saja kadang sesuatu yang kami buat masuk produk juga, dan saat itu tim hilir bertanggung jawab mengubah kode coretan menjadi kualitas produksi. Orang-orang itu membenci kami dengan kebencian yang membara
  • Saya pernah melihat cara ini bekerja sangat baik di tim kecil dengan tingkat kepercayaan tinggi dan sekitar 80% cakupan pengujian. Prosesnya tanpa PR; jika tes lulus, demo UX kepada stakeholder yang relevan berhasil bila diperlukan, dan orang yang mengerjakannya puas, maka ia merge ke master
    Anggota tim baru diberi mentor yang duduk di sebelahnya, sering pairing, dan meninjau kodenya selama 2–3 bulan pertama
    Proyeknya berlangsung 2,5 tahun, go-live pada bulan ke-20, memenuhi jadwal dan anggaran, serta memberikan lebih banyak fitur daripada cakupan awal. Pada banyak hari, kami berdiskusi 2–3 jam di depan whiteboard. Sifatnya informal dan tidak selalu semua orang ikut
    Anehnya, selama proyek ini PM berganti tiga kali. Ada aturan ketat bahwa selain standup, tidak ada email atau kontak, dan dua dari tiga orang itu bisa “bekerja” dengan pengaturan ini. Kepala IT bandara baru menyadari setelah 2 tahun bahwa kami tidak membutuhkan PM
    Ada aturan bahwa jika mengerjakan sesuatu yang baru di codebase, Anda harus berbicara dengan setidaknya satu developer lain. Kami duduk berdekatan dalam jarak beberapa kaki di kantor pribadi yang luas dengan whiteboard besar. Story dikelola dengan kartu indeks yang ditempel pada whiteboard khusus, dan jika inti ceritanya tidak bisa dijelaskan di sana, berarti harus dipecah menjadi bagian yang lebih kecil
    Setiap orang bisa merakit mesinnya sendiri dan memakai monitor sebanyak yang diinginkan. Ini adalah sistem penagihan dan tarif untuk bandara internasional besar, dan kepala departemen akuntansi, direktur, serta pengguna lain berada hanya beberapa pintu kantor dari kami. Mereka hampir tidak pernah melewatkan standup, dan memiliki kebijakan selalu menerima pertanyaan real-time kapan saja
    Standup biasanya bukan laporan status, melainkan diskusi informal, demo, dan tanya jawab. Untuk update status, cukup melihat kartu di whiteboard
    Sistem final meningkatkan pendapatan sebesar 8% sejak bulan pertama dan setiap bulan setelahnya. Direktur akuntansi harus menjelaskannya di depan dewan otoritas bandara. Sengketa dan penyesuaian penagihan dengan maskapai berkurang dari 9 hari per bulan menjadi 1 hari, dan beban kerja penagihan bulanan berkurang dari 18 hari menjadi 5 hari. Pengguna utama bisa dialihkan dari akuntan senior ke satu akuntan junior dengan pengalaman 3 tahun
    Bug produksi ada 6 kasus pada tahun pertama, dan faktur yang salah 0. Saya tidak punya data setelah itu. Upaya rewrite sebelumnya gagal setelah 3 tahun
  • Sejujurnya, dari sisi keamanan dan audit, ini terdengar seperti mimpi buruk. Tapi kalau agensi yang mengerjakan proyek kecil atau tempat serupa, mungkin masih masuk akal

• Menggunakan proses code review untuk menyandera perubahan sampai cocok dengan ideal tim yang tinggi dan terus berubah adalah disfungsi
  Kebijakan “upgrade sambil jalan” meninggalkan ekor panjang transisi setengah jadi, sehingga makin sulit bagi developer baru untuk beradaptasi dengan codebase. Tidak ada jaminan bahwa fokus produk akan secara berkala melewati setiap bagian codebase, sehingga transisinya tidak pernah selesai. Beberapa area produk dibiarkan begitu saja selama bertahun-tahun
  Jika transisi ke kebijakan baru itu penting, pekerjaan tersebut harus dipotong menjadi satu proyek terfokus; jika tidak, berarti itu tidak penting

  • Benar. Ini mengerikan karena manajemen pada dasarnya menelantarkan perencanaan
    Mereka berharap bom waktu pekerjaan tak terencana yang tersebar di seluruh codebase akan meledak lewat pekerjaan acak yang tidak terkait
    Jika standar baru itu penting, kodenya harus diperbarui; jika tidak, jangan. Mengandalkan keacakan dan memperlambat pekerjaan mendesak bukanlah rencana

• Membaca ini sebagai masalah code review itu keliru. Masalahnya adalah perusahaan menempatkan proses yang terdiri dari penghalang internal di atas prinsip
  Setiap proses membutuhkan jalan keluar. Jika perubahan itu mencegah pemecatan, semua jalan keluar seharusnya diaktifkan