“Technical Debt” dalam Software Development
Dalam development sebuah software, sebagai engineer sering kali kita berhadapan dengan penentuan berapa lama timeline yang dibutuhkan untuk men-develop sebuah fitur yang ideal dari sudut pandang engineer vs timeline yang diberikan oleh product team.
Timeline yang dipersingkat biasanya menghasilkan Technical Debt karena engineer tidak mempunyai waktu yang cukup untuk berpikir secara jangka panjang maupun memikirkan best overall solution dari sebuah code.
Sangat lumrah jika beberapa proses technical dipangkas oleh engineer untuk membantu product team mengejar momentum, terutama di Startup. Tapi tentu ada n̶y̶a̶w̶a̶ harga yang harus dibayar di kemudian hari.
Inilah yang disebut utang teknikal alias Technical Debt atau kita singkat “tech debt”.
Utang jika tidak dibayar, akan menghasilkan bunga. Semakin besar bunganya, semakin berat pula untuk melunasi utang. Jika kita tidak bisa membayar utang, semakin lama hidup kita akan semakin tidak nyaman karena bakal dikejar-kejar debt collector.
Ini juga terjadi terjadi dalam software development, tech debt yang besar akan mempersulit scalability dan maintenability dari sebuah software. Mungkin awalnya bisa saja kita “akali” implementasinya agar tetap bisa deliver. Tapi semakin lama, tech debt ini akan mengurangi produktivitas karena kita harus mencari cara kotor hingga akhirnya tidak bisa lagi menambahkan fitur sama sekali. Bahkan yang lebih buruk, kita juga akan kesulitan me-maintain software kita, karena ketika kita baca code nya, isinya tambal sulam sana-sini. Ruwet lah, kalo kata Pak Jokowi.
Lalu dengan apa kita membayarnya? Tentu saja dengan “refactoring”.
Oke, cukup intro-nya. Setelah ini saya ingin berbagi pengalaman tentang apa yang kami lakukan untuk mengatasi tech debt di Qasir.
Samakan Persepsi tentang Technical Debt
Hal pertama yang kami lakukan adalah menyamakan persepsi. Tidak semua stakeholder paham tentang tech debt. Biasanya yang sering disalahpahami adalah bugs, masalah UI /UX, dan fitur-fitur yang tertunda dianggap termasuk technical debt. Padahal sebenarnya tidak.
Saya suka penjelasan tech debt dari Agile Alliance ini:
“The Technical Debt concept is an effective way to communicate about the need for refactoring and improvement tasks related to the source code and its architecture.
Code issues may be related to architecture, structure, duplication, test coverage, comments and documentation, potential bugs, complexity, code smells, coding practices and style. All these types of issues incur technical debt because they have a negative impact on productivity.”
Singkatnya Technical Debt terjadi ketika kita membangun software secara cepat dan tidak mendesign untuk jangka panjang.
Hal-hal yang seperti bugs, UI/UX, fitur yang dikurangi, memang termasuk utang, tetapi tidak dikategorikan sebagai tech debt. Untuk mempermudah pemahaman, mari kita kategorikan jenis-jenis utang ini dengan istilah lain.
- Feature Debt. Contohnya adalah fitur yang delay, atau fitur yang butuh iterasi secara keseluruhan karena respon market-nya negatif.
- User Experience Debt. Contohnya ketika ada komponen UI/UX yang gagal untuk mengarahkan user untuk melakukan suatu hal.
- Quality Debt. Contohnya bugs yang muncul karena “cacat” dari sebuah code, atau terjadi error maupun crash.
- Technical Debt. Nah ini, tech debt lebih ke masalah-masalah teknis yang semakin lama memperlambat development dari waktu ke waktu. Seperti yang dibahas di atas, mulai dari architecture, structure, duplication, test coverage, comments and documentation, potential bugs, complexity, code smells, coding practices dan style.
Selain dari masalah code, tech debt juga mencakup masalah dari pihak ke-3. Bisa seperti code yang deprecated, Library yang sudah tidak di-maintain, ataupun kemajuan teknologi di platform yang kita pakai sehingga membuat code kita tidak relevan lagi dan membuat software yang kita buat cepat atau lambat sulit untuk scale-up dan di-maintain atau malah menurunkan produktivitas kita.
Setelah semua stakeholder sepemahaman, kita lanjut ke perencanaan dan eksekusinya.
Perencanaan dan Eksekusi
Tidak ada solusi yang singkat untuk menangani tech debt ini. Hal pertama yang kami lakukan adalah dokumentasi tech debt. Mendokumentasikan tech debt adalah hal yang wajib untuk engineer. Kemudian kita urutkan berdasarkan impact dan effort-nya. Setelah itu kita ajukan dan presentasikan ke product team untuk meminta waktu refactoring di dalam product roadmap.
Semudah itu? tidak juga. Kita harus bisa menerjemahkan manfaat teknis dari refactoring yang akan kita lakukan ke dalam kepentingan bisnis dan produk. (dibaca: meyakinkan tim produk). Hal ini sangat penting, karena ketika antar-stakeholder sama-sama mengerti konteks, urgency, dan mendapatkan nilai lebih dari sebuah refactoring, akan lebih mudah untuk product team memprioritaskan antara fitur / refactoring.
Strategi pertama yang kita lakukan adalah menyisipkan waktu 30% di tiap sprint untuk tech debt. Satu sprint umumnya mengalokasikan waktu 2 minggu yang dibagi menjadi 7 hari development dan 3 hari QA testing. Artinya kita bisa memakai 2 hari kerja itu tech debt di setiap sprint.
Tetapi untuk menyelesaikan tech debt yang kompleks, 30% tiap sprint itu sangat-sangat kurang dan sulit untuk memecah pekerjaannya untuk tiap sprint.
Strategi kedua yang kita lakukan sekarang adalah tech debt punya wadah sendiri yang dinamakan sprint cooldown dan dieksekusi tiap kuartal, dengan 1 sprint yang berdurasi 2 minggu (bisa lebih, bisa kurang, tergantung dengan pekerjaan refactoring apa yang kita angkat dan seberapa impact-nya).
Menurut saya, siklus cooldown ini cukup efektif jika dilakukan secara konsisten. Ingat, nggak ada yang namanya stop development berbulan-bulan untuk refactoring atau kita akan kehilangan market share dan keluar dari kompetisi bisnis itu sendiri.
Selain dari sprint cooldown yang kita punya, di engineering team juga menerapkan satu peraturan sederhana yang sangat berguna untuk tech debt yang sifat nya kecil-kecil: The Boy Scout Rule.
The Boy Scout Rule
Prinsip sederhana yang di adopsi dari Boy Scout Rule adalah:
“Leave the campground cleaner than you found it.”
Seorang pramuka, ketika selesai berkemah membiasakan diri untuk membersihkan tempat dia berkemah lebih bersih dari saat dia datang.
Setiap kali engineer mengubah sebuah code, engineer proaktif membersihkan code-smell yang ditemukan di class tersebut diluar dari fitur yang sedang dikerjakan.
Sederhananya seperti masalah typo, naming, kompleksitas sebuah method, style, duplikasi sebuah helper dan hal kecil lainnya bisa diatasi secara berkala dan tidak membutuhkan waktu yang lama menjadi kebiasaan yang sangat membantu mengurangi tech debt dan meningkatkan technical ownership.
Tidak ada yang salah dari strategi faster time-to-market. Tetapi stakeholder diluar engineering team harus punya awareness bahwa cepat atau lambat tech debt akan mengganggu kita.
Tech debt tidak akan pernah selesai selama software terus dikembangkan. yang kita perlukan adalah strategi untuk terus menjaga tech debt tidak menjadi monster untuk kita dan kita terus melakukan iterasi untuk hal ini.
By the way, ini tulisan pertama saya di Qasir. Silakan tekan tombol claps sebanyak-banyaknya jika tulisan ini bermanfaat, dan mari berdiskusi di kolom komentar tentang hal terkait yang mungkin tidak ter-cover artikel ini.
Terima Qasir.
