Bom waktu itu bernama technical debt

Istilah utang teknis (technical debt) pertama kali diperkenalkan oleh Ward Cunningham, salah satu penulis Agile Manifesto, yang membandingkan kompromi dalam pengembangan perangkat lunak dengan utang finansial. Sama seperti meminjam uang, mengambil jalan pintas teknis memungkinkan pencapaian tujuan lebih cepat, tetapi akan ada "bunga" yang harus dibayar di kemudian hari. Bunga ini terwujud dalam bentuk waktu dan upaya tambahan yang diperlukan untuk perbaikan. Parahnya sama halnya meminjam uang maka penggunaan solusi yang cepat saji itu seperti "Pinjol". 

Utang teknis bukan hanya sebatas kode yang berantakan. Kode yang berantakan adalah hasil dari kelalaian dan kurangnya profesionalisme. Sebaliknya, utang teknis sering kali merupakan keputusan sadar yang diambil berdasarkan kendala proyek yang nyata, dengan risiko yang diperhitungkan. Misalkan saja Developer menggunakan arsitektur monolitik kemudian di kemudian hari mengalami isu. 

Selain klasifikasi ini, utang teknis dapat bermanifestasi dalam berbagai bentuk, ini kita susun dalam secara prioritas

• Utang Arsitektur: Fondasi sistem yang kurang skalabel atau fleksibel.

• Utang Kode: Kode yang ditulis dengan terburu-buru, tidak konsisten, atau tanpa dokumentasi.

• Utang Pengujian: Kurangnya pengujian otomatis atau cakupan pengujian yang tidak memadai.

• Utang Dokumentasi: Dokumentasi yang tidak lengkap atau usang, membuat pemeliharaan menjadi sulit.

 Lalu bagaimana memperbaikinya, berikut adalah hal-hal yang perlu dilakukan:

1. Fondasi Arsitektur Perangkat Lunak yang Kokoh dengan mengadopsi SOLID principles SOLID Principle is still work in the modern era?
2. Memilih Pola Arsitektur Sesuai Skala Aplikasi. Pilihan arsitektur yang tidak sesuai dengan skala dan kompleksitas aplikasi adalah sumber utama dari utang arsitektur. Misalnya, memaksakan arsitektur microservices pada proyek kecil dapat menyebabkan over-engineering dan kompleksitas yang tidak perlu, sementara mempertahankan arsitektur monolitik untuk aplikasi berskala global akan menyebabkan masalah scalabilities dan pemeliharaan yang parah.
3. Strategi Deployment: dari pengembangan kode ke container based. Pendekatan ini cocok untuk proyek-proyek kecil, situs web statis, atau prototipe di mana kecepatan untuk "online" adalah prioritas utama dan kompleksitas operasional masih rendah. Namun, seiring pertumbuhan aplikasi, ketergantungan pada lingkungan build yang spesifik dan kurangnya portabilités dapat menjadi kendala.