Technical Debt

Tenggat demo besok pagi, dan ada satu jalan pintas: menulis solusi cepat yang bekerja tetapi meninggalkan struktur rapuh — tabel tanpa indeks, method 400 baris, validasi yang disebar ke lima tempat. Kita semua pernah mengambil jalan itu, dan sering kali keputusan tersebut memang benar. Yang membedakan tim sehat dari yang bermasalah bukan keberadaan jalan pintas, melainkan catatannya: apakah kompromi itu dicatat, dipantau, dan dilunasi — atau dibiarkan mengendap tanpa jejak. Technical debt (utang teknis) adalah metafora untuk kompromi semacam itu: kita meminjam kecepatan hari ini dan membayar bunganya setiap kali kode itu disentuh kembali. Pada Chapter ini kita akan memahami metaforanya, kuadran keputusannya, aritmetika bunganya, dan strategi pelunasannya.

Metafora Utang #

Kekuatan metafora utang terletak pada analogi keuangannya yang presisi. Mengambil utang berarti mendapatkan sesuatu sekarang (fitur terkirim lebih cepat) dengan kewajiban membayar kemudian (perubahan berikutnya di area itu menjadi lebih mahal). Bunga adalah tambahan biaya per sentuhan: struktur rapuh harus diurai dulu sebelum dimodifikasi. Dan seperti utang keuangan, utang teknis bisa menumpuk: solusi cepat di atas solusi cepat saling menguatkan hingga satu perubahan kecil memakan waktu berminggu-minggu.

Kapan berutang rasional? Ketika nilai kesempatan nyata dan rencana pelunasan jelas: demo investor minggu ini, eksperimen pasar dua minggu, atau keputusan sementara yang menunggu pustaka eksternal stabil. Berutang tanpa catatan dan tanpa rencana lunas adalah satu-satunya bentuk yang hampir selalu salah.

Kuadran Utang Teknis #

Martin Fowler merinci keputusan utang ke dalam kuadran dua sumbu: sengaja atau tidak disengaja, dan bijak atau gegabah. Hasilnya empat tipe keputusan dengan mutu berbeda:

Kuadran kiri atas adalah utang yang sehat: sadar, terdokumentasi, terjadwal. Kuadran kanan bawah paling berbahaya karena timnya tidak menyadari sedang berutang. Pergeseran antar kuadran juga terjadi secara alami: utang yang dulu sengaja dan bijak menjadi masalah ketika orang yang memahami konteksnya pergi tanpa meninggalkan dokumentasi.

Aritmetika Bunga #

Mari kita hitung bagaimana bunga bekerja. Simulasi berikut memodelkan satu area kode dengan biaya perubahan awal 8 jam; setiap perubahan menaikkan biaya perubahan berikutnya 20% karena solusi cepat menumpuk di atas solusi cepat:

public class BungaUtangTeknis {
    public static void main(String[] args) {
        double biayaAwal = 8.0;   // jam kerja untuk satu perubahan
        double bunga = 0.20;      // utang menaikkan biaya 20% per siklus
        int jumlahSiklus = 6;

        System.out.println("Siklus | Biaya perubahan (jam) | Total terbayar (jam)");
        double total = 0;
        double biaya = biayaAwal;
        for (int siklus = 1; siklus <= jumlahSiklus; siklus++) {
            total += biaya;
            System.out.printf("%6d | %22.1f | %19.1f%n", siklus, biaya, total);
            biaya = biaya + biaya * bunga;   // bunga menumpuk ke siklus berikutnya
        }

        double tanpaUtang = biayaAwal * jumlahSiklus;
        System.out.println();
        System.out.printf("Enam perubahan tanpa utang : %.1f jam%n", tanpaUtang);
        System.out.printf("Enam perubahan dengan utang: %.1f jam%n", total);
        System.out.printf("Bunga yang dibayar         : %.1f jam%n", total - tanpaUtang);
    }
}

Output yang Dihasilkan:

Siklus | Biaya perubahan (jam) | Total terbayar (jam)
     1 |                    8.0 |                 8.0
     2 |                    9.6 |                17.6
     3 |                   11.5 |                29.1
     4 |                   13.8 |                42.9
     5 |                   16.6 |                59.5
     6 |                   19.9 |                79.4

Enam perubahan tanpa utang : 48.0 jam
Enam perubahan dengan utang: 79.4 jam
Bunga yang dibayar         : 31.4 jam

Mari kita baca angka-angka tersebut sebagai cerita proyek:

1. Kolom Biaya perubahan: perubahan pertama 8 jam; keenam sudah 19,9 jam — lebih dari dua kali lipat dalam enam sentuhan. Pertumbuhan 20% per siklus terasa kecil sekali saja dalam satu angka, inilah yang membuat utang teknis begitu mudah diremehkan.
2. Kolom Total terbayar: akumulasi mencapai 79,4 jam untuk enam perubahan — 31,4 jam lebih banyak daripada tanpa utang. Selisih itu adalah bunga: pekerjaan yang tidak menghasilkan fitur apa pun bagi pengguna.
3. Titik impas pelunasan: bila melunasi utang (refactor) memakan 15 jam, pelunasan di siklus kedua sudah lebih murah daripada membayar bunga 31,4 jam. Keputusan melunasi adalah perhitungan, bukan rasa bersalah.
4. Asumsi yang perlu dicatat: model 20% per siklus adalah ilustrasi; utang nyata tidak tumbuh sekata. Angka ini menjelaskan bentuk kurva yang membuat utang terasa jinak di awal dan menindas di akhir.

Tanda-Tanda Utang Menumpuk #

Utang teknis tidak muncul di laporan keuangan, tetapi meninggalkan gejala yang dapat diamati:

• Estimasi menggelembung di area yang sama — fitur “sederhana” di modul tertentu selalu jauh lebih mahal.
• Rasa takut menyentuh — engineer menghindari berkas tertentu, atau perubahan di sana memicu bug tak terduga.
• Bug dibuka ulang — perbaikan yang sama kambuh karena akar masalah struktural tidak dilunasi.
• Onboarding melambat — anggota baru butuh waktu lama memahami alur yang tidak lagi mencerminkan desainnya.

Ritual mingguan sederhana menjaga gejala itu terlihat: tim meninjau item utang di backlog dan memprioritaskan angsuran berdasarkan frekuensi sentuhan — bukan berdasarkan siapa yang paling keras bersuara.

Strategi Anak Pramuka #

Dua strategi pelunasan melengkapi perencanaan besar. Pertama, aturan anak pramuka: setiap kali menyentuh sebuah area, tinggalkan sedikit lebih baik — ganti satu nama membingungkan, ekstrak satu method, hapus satu duplikasi; perubahan kecil itu tidak menunda fitur dan menjadikan pembayaran bunga menjadi momentum pelunasan. Kedua, alokasi tetap: sisihkan persentase tetap kapasitas tiap sprint (umumnya 10-20%) untuk melunasi utang berbunga tertinggi.

Kombinasi keduanya menjaga saldo: berutang tetap boleh diambil dengan sadar dan angsuran mengalir rutin. Bab terakhir dari rantai kualitas ini bukan lagi soal kode, melainkan soal orang: bagaimana tim saling memeriksa hasil kerja dengan cara yang membangun. Chapter berikutnya menutup Section ini dengan praktik code review.

Referensi #

• Martin Fowler — TechnicalDebt
• Martin Fowler — Technical Debt Quadrant

public class BungaUtangTeknis {
    public static void main(String[] args) {
        double biayaAwal = 8.0;   // jam kerja untuk satu perubahan
        double bunga = 0.20;      // utang menaikkan biaya 20% per siklus
        int jumlahSiklus = 6;

        System.out.println("Siklus | Biaya perubahan (jam) | Total terbayar (jam)");
        double total = 0;
        double biaya = biayaAwal;
        for (int siklus = 1; siklus <= jumlahSiklus; siklus++) {
            total += biaya;
            System.out.printf("%6d | %22.1f | %19.1f%n", siklus, biaya, total);
            biaya = biaya + biaya * bunga;   // bunga menumpuk ke siklus berikutnya
        }

        double tanpaUtang = biayaAwal * jumlahSiklus;
        System.out.println();
        System.out.printf("Enam perubahan tanpa utang : %.1f jam%n", tanpaUtang);
        System.out.printf("Enam perubahan dengan utang: %.1f jam%n", total);
        System.out.printf("Bunga yang dibayar         : %.1f jam%n", total - tanpaUtang);
    }
}