Utang Teknis

Utang teknis adalah akumulasi biaya dari pilihan implementasi yang dianggap tepat pada saat itu, tetapi membuat perubahan di masa mendatang menjadi lebih lambat atau lebih berisiko. Metafora ini berasal dari Ward Cunningham: meminjam dengan jaminan kapasitas di masa depan untuk merilis produk lebih cepat sekarang, dengan bunga yang dibayarkan pada setiap perubahan berikutnya hingga utang tersebut lunas. Seperti utang finansial, utang teknis tidak selalu buruk, dan perbedaan pentingnya adalah antara utang yang diambil secara sengaja karena suatu alasan dan utang yang terakumulasi karena kelalaian.

Nilai metafora ini terletak pada kemampuannya membuat pertukaran tersebut dapat didiskusikan dengan orang-orang yang tidak menulis kode. Membingkai permintaan refactoring sebagai pembayaran utang mengkomunikasikan sesuatu yang tidak dilakukan oleh permintaan untuk menulis ulang modul, yaitu bahwa biaya tersebut sudah dibayarkan, dalam bentuk pengiriman yang lebih lambat dan tingkat cacat yang lebih tinggi, dan pertanyaannya adalah apakah akan terus membayarnya. Rumusan asli Cunningham juga menekankan bahwa utang muncul dari kesenjangan yang semakin besar antara struktur kode dan pemahaman tim saat ini tentang masalah tersebut, yang merupakan gagasan yang lebih luas daripada sekadar menulis kode yang ceroboh di bawah tekanan tenggat waktu.

Beberapa hal berbeda dikelompokkan di bawah istilah tersebut, dan membutuhkan respons yang berbeda. Utang yang disengaja, yang diambil dengan sadar untuk memenuhi tenggat waktu nyata dengan rencana untuk mengatasinya, adalah keputusan teknik yang sah. Utang yang tidak disengaja, yang muncul karena pemahaman tim meningkat setelah desain ditetapkan, tidak dapat dihindari dan merupakan biaya normal dari pembelajaran. Utang karena kelalaian, dari pengujian yang tidak ada, perilaku yang tidak terdokumentasi, dan ketergantungan yang tidak dipelihara, menumpuk secara diam-diam dan merupakan kategori yang paling mahal karena membuat setiap perubahan menjadi lebih berisiko. Ketergantungan yang usang khususnya membawa risiko keamanan daripada sekadar ketidaknyamanan.

Gejala-gejala tersebut terlihat pada metrik pengiriman sebelum terlihat dalam kode. Estimasi yang meningkat untuk pekerjaan serupa, peningkatan porsi kapasitas yang dihabiskan untuk perbaikan cacat, keengganan untuk menyentuh area tertentu, dan perubahan di satu tempat yang merusak hal-hal yang tidak terkait, semuanya merupakan indikasi bahwa pembayaran bunga telah menjadi substansial. Tim sering melaporkan gejala-gejala ini sebagai masalah kapasitas dan meminta lebih banyak orang, yang biasanya memperburuk situasi dalam jangka pendek.

Mengelolanya membutuhkan pekerjaan yang terlihat dalam proses perencanaan yang sama dengan hal-hal lainnya. Hutang yang tercatat dalam daftar terpisah yang hanya ditangani ketika ada kapasitas luang tidak pernah ditangani, karena memang tidak pernah ada kapasitas luang. Mengalokasikan proporsi tetap dari setiap siklus untuk itu, atau melampirkan perbaikan pada pekerjaan fitur di area yang diubah, adalah dua pendekatan yang bertahan menghadapi tekanan komersial. Alternatifnya, penulisan ulang besar-besaran secara berkala, biasanya merupakan gejala dari penundaan pekerjaan yang terlalu lama, dan membawa risiko yang jauh lebih besar daripada peningkatan bertahap.

Mengkomunikasikan alasan perlunya perbaikan lebih efektif dalam konteks implementasi daripada dalam konteks rekayasa. Menyatakan bahwa area tertentu sekarang membutuhkan waktu tiga kali lebih lama untuk diubah daripada area yang sebanding, dengan bukti dari pekerjaan terbaru, menghubungkan masalah tersebut dengan sesuatu yang sudah dipedulikan oleh pemangku kepentingan non-teknis, sedangkan mendeskripsikan masalah arsitektur tidak. Di mana utang tersebut membawa risiko daripada biaya, seperti ketergantungan yang tidak terpelihara atau kurangnya cakupan pengujian pada jalur kritis, membingkainya sebagai paparan dengan probabilitas dan dampak lebih efektif daripada membingkainya sebagai kualitas. Dalam kedua kasus tersebut, mengukur biaya berkelanjutan adalah yang mengubah preferensi rekayasa menjadi kasus bisnis yang dapat bersaing dengan pengembangan fitur untuk kapasitas.

Tidak semua utang harus dibayar kembali. Kode yang berfungsi, jarang berubah, dan tidak menimbulkan masalah dapat tetap seperti apa adanya terlepas dari tampilannya, dan upaya yang dihabiskan untuk memperbaikinya tidak menghasilkan keuntungan. Pendekatan yang ekonomis memusatkan perbaikan di mana perubahan sering terjadi dan di mana bunga benar-benar dibayarkan. Membuat pertimbangan tersebut terlihat, dan menyisihkan kapasitas eksplisit untuk itu dalam perencanaan, adalah bagian normal dari cara kerja suatu sistem. pengembangan produk Keterlibatan ini terstruktur, dan termasuk dalam diskusi peta jalan di dalam sebuah studio produk alih-alih diperlakukan sebagai masalah teknik di luar percakapan produk.