Memahami Lebih Dalam Apa Itu Technical Debt

             

Pengertian

Technical Debt adalah Hutang Teknis. Sebuah konsep pemrograman yang menerapkan ‘asal sistem jalan dulu sesegera mungkin’ dibanding sistem yang diterapkan secara baik dan benar dalam segi arsitektur, coding maupung testing sangat memungkinkan pada saat development terbentuk Technical Debt. Jadi Technical Debt bisa disebut pilihan yang kita tanggung untuk mencapai sebuah tujuan spesifik yang lebih cepat. Pilihan ini suatu saat harus dibayar pada saat project atau sistem sudah live atau berjalan.

Tipe-tipe Technical Debt:

Menurut tulisan yang dipublikasikan oleh Software Engineering Institute yang berjudul “Towards on Ontology of Terms of Technical Debt” ada 13 tipe, yaitu:

-       Architecture Debt

-       Build Debt

-       Code Debt

-       Defect Debt

-       Design Debt

-       Documentation Debt

-       Infrastructure Debt

-       People Debt

-       Process Debt

-       Requirement Debt

-       Service Debt

-       Test Automation Debt

-       Test Debt

Ciri-ciri suatu project atau sistem yang mengandung Technical Debt:

1. Banyak Code Smells
2. Kompleksitas tinggi namun tidak menggunakan design pattern
3. Banyak Bugs yang dapat menyebabkan sistem crash
4. Bermasalah dengan coding style atau tidak menerapkan clean code

Penyebab

Dalam implementasi suatu project, terkadang management menginginkan suatu sistem yang cepet ter deliver dan cepat live agar segera menghasilkan cuan. Itu jika dilihat dari sisi bisnis. Sedangkan sisi tech pasti menginginkan sistem yang berkualitas dengan minim bugs dan mudah di enhance jika ada penambahan fitur baru. Hal ini sangat bersebrangan. Tech team mungkin butuh waktu yang lebih jika ingin men-deliver project-nya secara baik dan benar. Jadi terkadang tech team mengabaikan ‘baik dan benar’ itu agar project cepat ter-deliver dan mengabaikan hal-hal penting yang sebenarnya harus diterapkan agar sistem mempunyai kualitas yang baik.

Penyebab Technical Debt:

1. Deadline
   Sudah mendekati deadline dan tidak ada waktu untuk mendesain arsitektur yang sempurna dan melakukan banyak case untuk testing.
2. Bad Design
   Desain sistem yang sudah buruk dari awal menyebabkan sulitnya penambahan fitur baru, dan jika bisa dilakukan pun akan menyebabkan masalah yang semakin kompleks.
3. Poor skill
   Kurangnya keterampilan coding, kurangnya pelatihan dan pemahaman tentang coding dan design pattern, tidak adanya senior atau tech lead yang me-review setiap code yang dibuat akan menyebabkan Technical Debt.
4. Tekanan untuk segera ter-deliver
   Manajemen projek dengan timeline yang singkat namun tidak seimbang dengan banyaknya task yang harus selesai menjadi salah satu penyebab terbesar adanya Technical Debt.
5. Accelerate Velocity
   Dititik ini kita diharuskan mengambil keputusan antara memotong scope atau menambah waktu rilis suatu project. Tetapi manajemen tim biasanya menolak kedua opsi tersebut dan mengharuskan sistem berjalan dengan semua fitur dan dengan waktu yang sudah ditentukan. Disini dev team dituntut untuk mempercepat kecepatan untuk bisa mencapai release date. Dengan bekerja seperti ini, dev team akan dengan tidak sengaja melakukan Technical Debt. Mungkin desain sistem tidak akan sebagus yang semestinya, dan beberapa testing sistem tidak akan selengkap semestinya.
6. Sedikit testing
   Mitos yang sering dijumpai bahwa memperbanyak testing adalah penambahan waktu. Dengan menguranginya kita dapat mempercepat velocity. Tetapi realitasnya tidak seperti itu, pengurangan testing justru menambah Technical Debt. Best practice nya adalah melakukan TDD (Test Driven Development).
7. Technical Debt dibangun dari Technical Debt
   Technical Debt pada masa yang akan datang terbentuk dari Technical Debt saat ini yang dibiarkan. Hal ini dapat terjadi ketika kita tidak melakukan perbaikan apapun dan masalah menjadi kompleks.

Konsekuensi

Technical Debt jika dibiarkan suatu saat akan menjadi bom waktu. Bisa mengakibatkan turunnya performa sistem, sulitnya implementasi fitur baru, dan hal-hal negatif lainnya seperti:

1. Titik Kritis tidak dapat di perdiksi
   Technical Debt tumbuh secara tidak terduga dan tidak linier. Satu Technical Debt ketika bergabung dengan Technical Debt yang lain jauh lebih beresiko. Pada titik tertentu Technical Debt yang tergabung itu dapat mencapai ‘Masa Kritis’, dimana produk menjadi tidak terkelola atau kacau. Pada titik kritis, perubahan atau penambahan fitur kecil pada produk dapat menjadi peluang ketidakpastian. Misal penambahan fitur baru yang dapat menyenggol sistem yang sudah ada dikarenakan code yg tidak terstruktur. Atau sistem yang tiba-tiba down dikarenakan perubahan beberapa bagian.
2. Peningkatan waktu deliver
   Karena mengabaikan ‘baik dan benar’ saat membangun project atau menambahkan fitur, maka waktu deliver juga akan lebih singkat. Hal ini biasanya disukai oleh tim manajemen.
3. Jumlah cacat yang signifikan
   Produk atau sistem dengan Technical Debt yang signifikan menjadi lebih kompleks dan membuatnya lebih sulit untuk di develop atau di maintenance.
4. Naiknya biaya develop dan support
   Semakin banyak Technical Debt, semakin rumit proses development, support dan maintenance. Sehingga lebih banyak memakan biaya.
5. Development terhenti
   Ketika kita lebih memilih fixing Technical Debt dan menghentikan development, maka sistem akan menjadi kurang menarik bagi orang-orang yang berpotensi menjadi customer. Atau mereka yang sudah menggunakan produk atau sistem memilih beralh ke produk lain. Sehingga perlu manajemen Techincal Debt.
6. Menurunnya kemampuan memprediksi
   Produk atau sistem dengan Technical Debt yang tinggi membuat semua kemungkinan prediksi menjadi tidak mungkin. Contohnya estimasi menjadi sulit bahkan untuk anggota tim yang sudah berpengalaman.
7. Dibawah performa
   Ketika Technical Debt tinggi, maka dev team akan berada di bawah performa. Mereka akan sulit men develop fitur baru dan membutuhkan waktu yang labih.
8. Membuat frustasi
   Technical Debt yang tinggi membuat dev team frustasi saat mengerjakan penambahan fitur atau perubahan, menyebabkan penambahan waktu pada timeline project dan membuat project manager juga frustasi. Ketika timeline membengkak maka manajemen tim pun akan terkena dampaknya dan menjadi ikut frustasi. Dan semua orang menjadi frustasi.
9. Kepuasan customer menurun
   Kepuasan customer akan produk atau sistem kita menjadi menurun dan tingkat frustasi mereka bertambah. Jadi efek Technical Debt tidak hanya dirasakan oleh dev team, tetapi juga customer. Misal adanya bugs, atau fitur yang masih belum stabil dan menyusahkan customer.

Cara mengatasi

Technical Debt yang sudah terbentuk harus segera diatasi sebelum semakin kompleks dan menyebabkan banyak masalah. Hal-hal yang dapat dilakukan untuk menghilangkan Technical Debt seperti:

1. Identifikasi existing Technical Debt
   Mengidentifikasi Technical Debt dapat menggunakan tool seperti SonarQube. SonarQube membantu mengkategorikan Technical Debt seperti duplication, rule violation, code coverage, complexity, documentation dll dan menyediakan bentuk visual Technical Debt dan rencana untuk memperbaikinya. Metode lain dapat menggunakan SCALE (Software Quality Assessment based on Lifecycle Expectation) yang mengkategorikan hal-hal seperti changeability, maintainability, security, reliability, testability, efficiency, and portability. SCALE juga tersedia sebagai plugin di SonarQube.
2. Klarifikasi sejelas mungkin mengenai sumber masalah yang menyebabkan Technical Debt termasuk tujuan bisnis, source code, testing, design dan infrastruktur.
3. Analisa mana Technical Debt yang ringan atau yang berat. Yang membutuhakan waktu lama dan yang membutuhkan sedikit waktu. Prioritaskan yang memang lebih butuh untuk segera diperbaiki.
4. Pilih solusi terbaik untuk setiap Technical Debt: eliminate, reduce, atau mitigate.
5. Praktikan development yang dapat mengurangi Technical Debt seperti Agile. Agile mengurangi cakupan yang akan di rilis dengan waktu yang sudah ditentukan sendiri oleh tim dev dibanding merilis sistem yang besar dengan fungsi yang banyak dan dengan estimasi waktu dari Project Manager. Dalam Agile kita dapat menyisipkan task-task kecil untuk mengurangi atau melakukan refactoring terhadap Technical Debt yang ada.
6. Memonitor Technical Debt
   Setelah sedikit demi sedikit Technical Debt dikurangi, tetaplah lakukan monitoring. Apakah Technical Debt benar-benar berkurang atau malah menyebabkan Technical Debt yang lain. Pastikan juga perbaikan Technical Debt tidak mengganggu berjalannya sistem.

Waktu yang tepat untuk membayar Technical Debt

1. Ketika menambahkan fitur
   Ketika menambahkan fitur baru dan fitur itu dibangun diatas Technical Debt, cobalah untuk mem-fixing Technical Debt nya terlebih dahulu kemudian tambahkan fitur baru yang lebih clean code dan tanpa Technical Debt. Hal ini jika dilakukan secara terus menerus akan mengurangi Technical Debt yang ada.
   Jika kita tetap membangun fitur baru dan mengabaikan Technical Debt, ada kemungkinan fitur kita juga akan menjadi Technical Debt dan akan lebih menyusahkan untuk developer selanjutnya.
2. Ketika bug fixing
   Bug fixing adalah saat yang tepat untuk clean code kode yang sudah ada. Ketika kita membetulkan bugs, sekalian merapihkan kode nya juga untuk mengurangi Technical Debt.
3. Ketika Code Review
   Code Review sangat dibutuhkan untuk mereka yang baru di dunia coding. Dengan Code Review yang dilakukan oleh senior atau Tech Lead maka akan ditemukan kesalahan-kesalahan developer saat coding. Dan disini bisa menghilangkan hal-hal yang akan menyebabkan code menjadi Technical Debt.

Tidak semua Technical Debt harus dibayar

Ada kalanya Technical Debt lebih baik dibiarkan dari pada kita membersihkannya, namun hal ini jarang terjadi. Berikut adalah kondisi dimana Technical Debt tidak harus dihilangkan:

1. Sistem atau project akan berakhir masa penggunaannya
   Sistem atau project yang akan berakhir masa penggunaannya lebih baik tidak dibersihkan Technical Debt nya. Karena akan memakan waktu dan biaya untuk hal yang juga tidak akan digunakan lagi. Misal, Project A akan digantikan oleh Project B dengan teknologi yang berbeda. Meskipun project A masih digunakan sampai pada saat project B live, lebih baik memastikan project B tidak mengandung Technical Debt daripada membereskan project A. Toh project A tidak akan digunakan lagi.
   
   
2. Throwaway prototype
   Project atau sistem yang dibangun untuk tujuan knowledge-acquisition nilainya bukan pada code nya, melainkan pada fungsi-fungsi yang akan ditunjukan kepada user bagaimana nantinya project akan jadi. Prototype tidak digunakan untuk live di prod.
3. Project dibangun untuk waktu yang sebentar
   Hal ini jarang terjadi, tetapi masih ada kemungkinannya. Jika kita membangun sistem atau project untuk waktu yang sebentar, Technical Debt tidak perlu dibayar.

Referensi:

[1] Kenneth S. Rubin. Essential Scrum, A Practical Guide To The Most Popular Agile Process

[2] Managing Technical Debt: Reducing Friction in Software Development https://learning.oreilly.com/library/view/managing-technical-debt/9780135646052/

[3] Product Management: Technical Debt https://www.productplan.com/glossary/technical-debt/

[4] Technical Debt Explained: The Complete Guide to Understanding and Dealing with Technical Debt https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/

[5] Apakakah bug bagian dari hutang teknis? https://qastack.id/software/207060/are-bugs-part-of-technical-debt

[6] When to Refactor https://refactoring.guru/refactoring/when