Apa Itu Technical Debt?

Technical Debt adalah konsep rekayasa software yang berkaitan dengan struktur data, pemrograman, arsitektur, pengujian, deployment, atau operasi sistem untuk membangun aplikasi yang dapat dipelihara. Secara operasional, Technical Debt membantu memberi struktur pada pekerjaan yang berhubungan dengan rekayasa perangkat lunak, arsitektur, testing, deployment, dan operasi, terutama ketika hasil harus dapat diukur dan diulang.

Kualitas penerapan sangat bergantung pada kejelasan data, tanggung jawab, dan batasan. requirement, code dan dependency perlu divalidasi, sedangkan lead time, deployment frequency dan defect rate dipakai untuk membedakan perbaikan nyata dari fluktuasi biasa.

1. Untuk Technical Debt, tentukan konteks penggunaan Technical Debt dan keputusan apa yang perlu dibantu oleh istilah ini.
2. Identifikasi komponen yang terlibat, misalnya requirement, code, dan source code.
3. Terapkan pada ruang lingkup yang jelas dan dokumentasikan asumsi agar tim memakai definisi yang sama.
4. Evaluasi dampaknya menggunakan indikator seperti lead time dan deployment frequency.

• Membuat eksperimen dan perbaikan berikutnya lebih cepat karena pembelajaran sebelumnya terdokumentasi.
• Membantu memisahkan masalah data, proses, teknologi, dan keputusan sehingga perbaikannya lebih tepat sasaran.
• Membuat hasil Technical Debt dapat ditinjau bersama indikator seperti lead time, deployment frequency, dan defect rate.
• Membantu mendeteksi risiko lebih awal sebelum berdampak pada pengguna, biaya, atau stabilitas proses.

Tim biasanya membutuhkan Technical Debt ketika aplikasi tumbuh besar dan batas antar modul mulai sulit dipahami. Gunakan CI pipeline untuk menyamakan konteks, data, dan keputusan yang akan diambil. Hasilnya dapat ditinjau melalui lead time dan deployment frequency.

Contohnya, aplikasi tumbuh besar dan batas antar modul mulai sulit dipahami. Tim mendokumentasikan kondisi awal dalam test suite, menerapkan Technical Debt pada ruang lingkup terbatas, lalu membandingkan deployment frequency dengan latency. Hasil dan alasan perubahan dicatat pada runbook sebelum pendekatan diperluas.

• Menerapkan Technical Debt tanpa menjelaskan tujuan, baseline, dan keputusan apa yang akan dipengaruhi.
• Menggunakan data yang periodenya, definisinya, atau sumbernya berbeda lalu membandingkannya seolah setara.
• Mengejar satu metrik sambil mengabaikan kualitas, biaya, pengalaman pengguna, atau risiko.
• Tidak menyimpan log, baseline, atau catatan perubahan sehingga masalah yang sama sulit ditelusuri.