- Codebase Drag adalah kondisi codebase yang membuat semua pekerjaan memakan waktu lebih lama dari yang seharusnya, namun tidak terlihat di dashboard atau laporan sprint sehingga kepemimpinan terus terjebak dalam siklus salah paham yang menganggapnya sebagai 'masalah orang'
- Hasil Audit codebase selama bertahun-tahun menunjukkan 5 sinyal yang sama terus berulang, dan diperkenalkan rubrik diagnosis kuantitatif bernama 'audit codebase drag' yang menilainya dari 0 hingga 2 poin
- Lima sinyal seperti pembengkakan estimasi, ketakutan deploy, file yang dilarang disentuh, kebohongan coverage, dan waktu hingga commit pertama semuanya berasal dari masalah kualitas codebase, dan berbeda dari kurangnya kemampuan orang
- Semakin berpengalaman seorang engineer, semakin baik ia mengenali risiko codebase dan bergerak lebih hati-hati, sehingga muncul paradoks bahwa mereka justru terlihat lebih lambat; jika ini disalahartikan sebagai masalah talenta, akibatnya hanya penambahan proses yang kontraproduktif
- Skor 4 atau lebih berarti codebase membutuhkan investasi langsung, dan skor 7 atau lebih menunjukkan perlunya intervensi struktural segera
Apa itu codebase drag
- Codebase Drag adalah fenomena ketika codebase membuat semua pekerjaan memakan waktu lebih lama dari yang seharusnya, dan ini tidak muncul dalam laporan sprint atau dashboard
- Contoh: tim klien menghabiskan 1 minggu dengan 2 engineer untuk menambahkan fitur ekspor CSV ke panel admin — pekerjaan nyatanya hanya setara 1 hari, sedangkan sisa waktunya habis untuk memahami cara mengubah kode lama dengan aman
- Ketika perlambatan kecepatan tim terus berulang, kepemimpinan menilainya sebagai masalah talenta lalu merespons dengan reorganisasi, penambahan proses, atau pergantian orang, tetapi tim berikutnya tetap menabrak dinding yang sama
- Akar masalahnya bukan bug, bukan fitur yang hilang, dan bukan pula technical debt dalam pengertian umum, melainkan codebase itu sendiri
5 sinyal codebase drag
1. Estimasi minta maaf (Apology Estimate)
- Situasi ketika engineer memberi estimasi 2 minggu untuk fitur yang sebenarnya butuh 3 hari, dan kepemimpinan salah mengartikannya sebagai pembengkakan jadwal
- Alasan sebenarnya adalah coupling antarmodul saat perubahan pada modul billing ikut menyentuh sistem notification, serta struktur yang membuat dampak perubahan tidak bisa diperkirakan dengan jelas
- Karena hidden default scope atau callback yang bersarang dalam, blast radius perubahan tidak bisa diprediksi tanpa membaca separuh codebase
- Jika estimasi secara konsisten memakan waktu 2~3 kali dari perkiraan, itu bukan masalah cara mengestimasi melainkan masalah biaya codebase
2. Ketakutan deploy (Deploy Fear)
- Muncul pola tim menghindari deploy pada hari Jumat, atau menggabungkan deploy menjadi rilis besar yang jarang dilakukan
- Satu tim klien menjalankan aturan tidak resmi untuk melarang deploy setelah hari Rabu — kebiasaan ini muncul setelah 3 deploy pada hari Kamis berujung insiden akhir pekan
- Penyebabnya adalah tidak adanya strategi rollback, test yang tidak dapat dipercaya, dan pipeline deploy 45 menit
- Menurut standar DORA, tim elite memiliki change failure rate di bawah 5% dan bisa deploy kapan pun diperlukan, tetapi tim ini berada dalam kondisi deploy seminggu sekali sambil menunggu dengan cemas
3. File 'jangan disentuh' (Don't Touch That File)
- Di hampir semua tempat, kalimat "jangan sentuh file itu" muncul dalam 2 hari pertama
- Misalnya billing controller dengan 30
before_action, atau model yang berada di bagian atas git log tetapi secara struktural nyaris tak pernah disentuh selama bertahun-tahun
- Saat menjalankan
git log --oneline --since="2 years ago", file yang paling sering diubah selalu file yang sudah diperingatkan itu — jika yang berulang hanya patch kecil dan tidak ada pekerjaan struktural, artinya gejala hanya ditangani sementara penyakitnya dibiarkan
- Biaya sesungguhnya adalah fungsi yang seharusnya berada di modul tersebut malah diimplementasikan di tempat lain, dan karyawan baru belajar menghindari file itu pada minggu pertama — codebase tumbuh secara menyimpang mengelilingi zona mati
4. Kebohongan coverage (Coverage Lie)
- Angka test coverage 80% terlihat sehat, tetapi sebenarnya nilai itu ditopang oleh test serializer, helper, dan utility yang hampir tidak pernah rusak, sementara 3 model inti yang menangani uang sama sekali tidak memiliki test
- Test suite ada bukan untuk menangkap regresi, tetapi agar metrik terlihat bagus — test lolos, tetapi production tetap rusak
- Waktu CI 40 menit membuat developer berhenti menjalankan test secara lokal → angka coverage berbohong dalam dua hal: bagian penting tidak tercakup, dan bahkan test yang ada pun tidak dijalankan
- Pertanyaan yang sebenarnya penting bukan angka coverage, melainkan "kapan terakhir kali test menangkap bug sebelum masuk ke production"
5. Waktu hingga commit pertama (Time to First Commit)
- Mengukur waktu dari saat engineer baru diberi laptop hingga ia membuka PR berisi perbaikan bug nyata atau fitur kecil
- Codebase sehat: 1~2 hari
- Codebase yang sedang drag: lebih dari 2 minggu
- Salah satu klien membutuhkan waktu berminggu-minggu untuk menyiapkan lingkungan pengembangan, tetapi setelah diperbaiki, developer baru bisa menyelesaikan setup dalam 15~20 menit
- Penyebab utamanya adalah setup rot — skrip
bin/setup tidak diperbarui sejak perubahan environment terakhir, seed data merujuk ke tabel atau kolom yang sudah tidak ada, dan ada 3 environment variable tak terdokumentasi yang baru diketahui saat aplikasi gagal berjalan
- Engineer lama sudah menginternalisasi prosedur yang tidak terdokumentasi, sehingga justru karyawan baru yang paling akurat memperlihatkan besarnya pengetahuan implisit yang dituntut codebase
Mengapa engineer bagus terlihat lambat di codebase yang buruk
- Kelima sinyal ini bekerja secara gabungan dan menambahkan overhead pada setiap pekerjaan yang tidak bisa ditunjuk dengan jelas saat standup
- Engineer yang di pekerjaan sebelumnya bisa menyelesaikan fitur dalam 2 hari kini butuh 1 minggu di codebase ini, dan ketika mencoba menjelaskan alasannya, itu terdengar seperti alasan belaka
- Hasil riset METR 2025 menunjukkan developer berpengalaman justru 19% lebih lambat saat memakai alat AI — bukti bahwa bottleneck-nya bukan mengetik
- Semakin baik engineer, semakin tajam ia mengenali risiko sehingga bergerak lebih hati-hati dan memberi estimasi yang lebih longgar — engineer yang kurang berpengalaman tidak melihat risikonya, deploy lebih cepat, lalu memicu gangguan production dan membuat seluruh tim menjadi makin berhati-hati dalam lingkaran setan
- Satu klien mengganti 6 tim dalam 10 tahun, termasuk 2 akuisisi penuh — pola yang berulang adalah tuntutan fitur dari kepemimpinan → melewati penanganan debt → kode masuk ke kondisi tak bisa dipulihkan → muncul usulan rewrite atau pemisahan microservices → sistem terbelah dua dan keadaan makin buruk
- Ketika kepemimpinan membaca perlambatan sebagai masalah talenta, mereka hanya menambahkan proses pada tim yang sudah penuh gesekan, sehingga situasi memburuk — satu-satunya intervensi yang benar-benar membantu adalah memperbaiki jalurnya sendiri
Audit codebase drag: cara mendiagnosis
- Nilai masing-masing dari 5 sinyal dengan skor 0~2:
- 0 poin: tidak ada masalah
- 1 poin: masalah parsial
- 2 poin: masalah serius
- Jika total 4 poin atau lebih, investasi langsung pada codebase harus didahulukan dibanding tindakan lain
Cara merespons saat technical debt menyeret tim ke bawah
- Mulai dari satu sinyal dengan skor tertinggi — jangan mencoba memperbaiki semuanya sekaligus
- Ketakutan deploy skor 2: prioritaskan kecepatan CI, otomatisasi rollback, dan perbaikan unit deploy yang lebih kecil
- Estimasi minta maaf peringkat 1: prioritaskan decoupling modul dengan blast radius paling luas
- Waktu hingga commit pertama skor 2: investasi 1 hari untuk memperbaiki
bin/setup dan mendokumentasikan environment bisa terbayar di semua perekrutan berikutnya
- Jika versi Rails tertinggal beberapa rilis, upgrade versi bisa menjadi forcing function yang membenarkan investasi
- Ukur per 2 minggu: pilih sinyal dengan skor tertinggi → sprint terfokus → ukur angka konkret (frekuensi deploy, akurasi estimasi, waktu ke PR pertama, dll.)
- Sulit memperoleh persetujuan investasi karena biaya jika tidak dilakukan tidak terlihat — mengatakan "ada technical debt" jauh kurang meyakinkan daripada "coupling tiga modul ini membuat semua fitur memakan waktu hampir dua kali lipat"
- Skor 7 atau lebih umumnya berarti sudah saatnya memulai dengan audit codebase selama 1 minggu
5 komentar
Memang benar, proyek legacy itu benar-benar penyakit kronis.
Ada yang malah lebih buruk daripada bikin ulang dari nol.
Ini tentangku ..?
Sepertinya ini tulisan yang sangat penting untuk benar-benar menekan biaya pemeliharaan.
Itulah sebabnya kadang menulis ulang dari nol justru bisa lebih cepat.
Semua orang tahu bahwa merapikan codebase adalah jalan untuk meningkatkan kecepatan dalam jangka panjang,
tetapi itu kurang lebih setara dengan mengatakan bahwa makan dengan baik, berolahraga, dan tidur cukup akan membuat kita lebih sehat.