Technical Debt — Tanggung Jawab Siapa?
Dalam pengembangan software, kita tidak selalu dihadapi dengan kondisi ideal dimana requirements selalu terjabarkan dengan jelas dan tidak mudah berubah — ubah.
Kita tidak selalu dapat memberikan estimasi yang tepat tentang berapa lama sebuah software dapat dikerjakan, selalu saja ada yang luput.
Kondisi tim tidak selalu ideal dimana komposisi senior — mid — junior engineers berada dalam jumlah yang tepat.
Dalam project management kita mengenal istilah — Project Management Triangle.
Terutama pada startup, dimana kecepatan delivery adalah suatu hal yang penting, kualitas kodingan akhirnya yang harus di korbankan. Sebut saja hal hal seperti :
- kodingan yang tidak mengandung unit test
- kodingan yang terlalu banyak mengandung fungsi dan class yang berulang
- penamaan variabel, fungsi, atau class yang tidak konsistent dan ambigu
- terdapat fungsi yang melakukan banyak hal sekaligus
Adalah beberapa ciri dari kodingan yang berkualitas rendah, yang pada akhirnya berujung pada — Tech Debt.
Kita tahu bahwa tech debt itu bukan sesuatu yang baik. Namanya juga hutang, nggak ada yang baik dan suatu saat nanti harus kita bayar. Dan seperti hutang pada umumnya, biasanya memiliki bunga. Semakin lama dan semakin besar hutang yang kita punya semakin besar juga bunga yang harus kita bayar.
Bunga, dalam software engineering ibarat waktu yang harus kita habiskan dalam menangani kodingan dengan kualitas rendah tersebut. Mungkin kita pernah merasakan bagaimana sulitnya ketika ingin mengubah sebuah fungsi bernama getData() yang sebenarnya melakukan data fetching, parsing, manipulasi dan menampilkan sekaligus. Atau mungkin kita pernah menghabiskan waktu menulis kode yang sama berulang ulang karena secara design tidak mendukung konsep reusable.
Tantangan
Kadang sebagai software engineers, kita selalu mengeluhkan hal tersebut dan blaming tim bisnis atau product yang selalu menambahkan fitur baru tanpa memikirkan soal tech debt.
Kita kesal karena yang mereka pedulikan adalah bagaimana caranya kita bisa memperbaiki bug sesegera mungkin tanpa memperhatikan bahwa sebenarnya hal tersebut muncul karena adanya tech debt yang sudah mengakar.
Hadapi saja, itu memang bukan tanggung jawab mereka sepenuhnya. Tapi itu adalah tantangan bagi kita sebagai software engineers. Karena tech debt, sepertinya hal nya architecture, adalah hal yang tidak dapat lihat oleh kacamata tim non engineer.
Attitude yang tepat bagi kita sebagai software engineers adalah, stop complaining and take actions.
Lalu langkah apa yang bisa kita ambil?
Ukur
Langkah pertama tentunya adalah mengukur seberapa besar hutang yang kita punya. Ada beberapa metrics yang dapat kita gunakan, diantaranya :
- Code coverage. Metrics yang dapat kita gunakan untuk mengukur seberapa banyak kodingan yang sudah memiliki test.
- Cyclomatic complexity. Metrics yang dapat kita gunakan untuk menghitung kompleksitas sebuah fungsi atau class dengan menganalisa jumlah conditional seperti if-then-else/switch-case dibandingkan dengan jumlah line of code. Semakin tinggi semakin sulit kodingan tersebut untuk dibaca.
- Bug count. Walaupun tidak serta merta ketika aplikasi tersebut memiliki bug berarti aplikasi tersebut memiliki tech debt, tapi metrics ini dapat menjadi tanda bagi kita untuk melihat lebih dalam apakah dari segi architecture, aplikasi kita sudah dirancang dengan baik.
- Kecepatan delivery. Kita bisa melihatnya dari time to pull request. Yaitu waktu yang dibutuhkan seorang engineer dari memulai mengerjakan sebuah task hingga ia membuka pull request. Memang metrics ini belum tentu langsung berkolerasi dengan tech debt, namun jika dalam komposisi tim yang sama dan beban tugas yang sama waktu yang dibutuhkan lambat laun semakin lama, adalah salah satu indikasi tech debt.
Salah satu tools yang menurut saya cukup lengkap untuk dapat mengukur hal hal tersebut adalah : Sonarqube.
Sonarqube memiliki beberapa rules yang dapat disesuaikan dengan bahasa pemrograman yang digunakan. Sonarqube akan menganalisa kodingan kita terhadap rules yang dimilikinya dan memberikan report di dashboard nya.
Saya tidak akan membahas lebih lanjut soal Sonarqube, karena post ini bukan tentang tools saja — dan saya juga tidak di endorse untuk melakukan itu :)
Hasil analisa dari tools seperti Sonarqube memang tidak memiliki 100% akurasi untuk memberikan gambaran kita terhadap tech debt yang kita punya. Tapi paling tidak, tools tersebut dapat membantu kita ke langkah selanjutnya.
Eksekusi
Sampai pada tahap ini kita tahu seberapa besar tech debt yang kita punya, langkah selanjutnya adalah buat action plan. Tidak perlu terlalu detail pada tahap ini, karena kita akan merincikannya lagi nanti. Bersamaan dengan membentuk action plan kita juga perlu menentukan standard baru yang ingin kita tuju. Contohnya jika kita belum memiliki code convention yang baik, maka ini adalah saatnya untuk menentukan.
Langkah selanjutnya yang paling penting adalah : komunikasikan.
Seperti yang sudah saya sebutkan, tech debt adalah sesuatu yang tidak nampak dengan jelas, berbeda dengan bug atau feature. Maka dari itu perlu adanya komunikasi yang jelas dan baik dalam menjelaskan kondisi hal tersebut.
Berbekal data yang kita dapatkan dari metrics diatas dan berikan alasan yang masuk akal — relasikan besarnya tech debt dengan bagaimana jumlah bug yang muncul dan kecepatan kita dalam men-delivery fitur baru — komunikasikan hal tersebut dengan orang atau tim yang bertanggung jawab dalam memprioritaskan project yang akan dikerjakan selanjutnya.
Jika organisasi mu mengadopsi Scrum, coba komunikasikan hal tersebut dengan Product Owner. Perlakukan tech debt sebagai task di backlog seperti hal nya penambahan fitur baru. Jika task terlalu besar, pecah menjadi bagian bagian yang lebih kecil dan berikan acceptence criteria yang jelas. Gunakan metrics diatas untuk mengukur apakah acceptence criteria tersebut telah tercapai. Prioritaskan bersama PO apa saja yang bisa kita lakukan di setiap sprint nya.
Jika hal tersebut dilihat tidak memungkinkan, coba strategi lain dengan menambahkan kriteria kodingan yang berkualitas dalam Definition of Done pada setiap sprint yang akan dilakukan. Paling tidak hal tersebut akan menjaga agar tech debt tidak lagi bertambah. Seperti hal nya : code coverage kodingan baru harus mencapai x% dan sesuai dengan code convention. Hal tersebut tentunya akan memperlambat pekerjaan engineers diawal, maka dari itu hati hati ketika memberikan estimasi dalam sebuah sprint.
Kesimpulan
Kondisi tidak ideal dimana kecepatan dan cost untuk mendeliver sebuah software diutamakan, mengakibatkan kodingan berkualitas rendah yang dihasilkan. Hal tersebut yang akhirnya memunculkan tech debt.
Tech debt sebenarnya menjadi tantangan tersendiri untuk sebuah organisasi apapun yang mengembangkan software. Sayangnya, tech debt tidak nampak ke permukaan seperti bug atau feature. Maka dari itu kesadaran software engineers dalam menemukan dan menghadapinya diperlukan.
Beberapa langkah yang bisa dilakukan meminimalisirkannya adalah dengan : mengukur, membuat action plan, komunikasikan dan tentunya eksekusi.
