Dalam dunia teknologi yang serba cepat saat ini, kita terlalu terfokus pada pengiriman produk dengan cepat hingga kita kehilangan pandangan tentang apa yang diperlukan untuk membangun sesuatu yang dapat bertahan lama. Penekanan ada pada merilis sesuatu---apa pun---secepat mungkin, daripada meluangkan waktu untuk memastikan keberlanjutan jangka panjang. Budaya minimum viable product (MVP) dan iterasi cepat, yang awalnya menjanjikan untuk membuat pengembangan perangkat lunak lebih efisien, justru mendorong kita ke dalam pola pikir di mana perangkat lunak diperlakukan seperti barang sekali pakai. Setelah sebuah produk diluncurkan, itu menjadi masalah orang lain untuk merawatnya.
Akibatnya, perangkat lunak menjadi lebih fokus pada kecepatan peluncuran daripada ketahanan kode. Dalam kesibukan untuk mengirimkan sesuatu, maintenance menjadi sebuah pemikiran kedua, bahkan jarang dipertimbangkan sama sekali. Sistem perangkat lunak diburu untuk diproduksi dengan mentalitas "nanti akan diperbaiki", dan "nanti" itu sering kali tidak pernah datang.
Pergeseran fokus ini bukanlah tren sementara; ini adalah masalah yang sudah tertanam dalam budaya rekayasa perangkat lunak modern. Obsesi industri terhadap pengiriman yang cepat telah mengubah cara kita melihat siklus hidup sistem perangkat lunak. Masalah dengan ini adalah bahwa sebagian besar umur suatu sistem tidak dihabiskan dalam fase pengembangan; sebagian besar dihabiskan dalam fase maintenance.
Kita Menukar Ketahanan dengan Kecepatan Pengiriman
Alat dan praktik yang kita gunakan---Agile, DevOps, CI/CD---seharusnya membantu kita mengirimkan perangkat lunak dengan cara yang lebih efisien dan berkelanjutan. Mereka dimaksudkan untuk membantu tim beriterasi dengan cepat, beradaptasi dengan perubahan, dan mengirimkan produk yang lebih baik. Namun, entah bagaimana, alat-alat ini telah dipakai untuk memprioritaskan kecepatan di atas segalanya. Kita mengorbankan kualitas jangka panjang demi kecepatan jangka pendek, dan hasilnya sering kali menghancurkan.
Banyak pengembang yang bisa memahami frustrasi ketika mewarisi kode yang terasa seperti penggalian arkeologi. Ketika kita mewarisi sebuah proyek, kita harus memecahkan teka-teki dari keputusan-keputusan yang diambil tergesa-gesa, seringkali tanpa dokumentasi yang jelas atau pengujian yang memadai. Lapisan demi lapisan kekacauan terakumulasi seiring waktu, karena setiap perubahan dilakukan dengan harapan bahwa "nanti akan dibersihkan". Ini adalah pola pikir yang berbahaya, dan sistem yang rapuh itulah yang harus kita hadapi setiap hari.
Dalam banyak organisasi, proyek perangkat lunak sering kali dipandang sebagai entitas yang dapat dihentikan begitu saja jika sudah tidak relevan lagi. Ketika produk atau fitur baru diluncurkan, ada banyak sorotan dan kegembiraan. Namun, setelah peluncuran, tanggung jawab terhadap perangkat lunak tersebut diserahkan kepada tim maintenance yang jarang mendapatkan penghargaan atau dukungan yang layak. Pekerjaan mereka yang penting---memperbarui dependency, memperbaiki bug, dan menjaga kestabilan sistem---sering kali terlupakan.
Tech Debt sebagai Model Bisnis
Bagi banyak startup, technical debt bukan hanya ditoleransi---itu sengaja dijadikan bagian dari strategi bisnis. Taruhannya sederhana: bergerak cepat, mencari market fit, dan menghadapi konsekuensinya nanti, atau tidak sama sekali. Produk mungkin akan mendapatkan pengguna, atau menarik investor, cukup cepat untuk membenarkan kekacauan yang ada. Dan jika tidak berhasil, codebase-nya akan menjadi korban yang dilupakan.
Ketika startup ini berhasil, sering kali pengembanglah yang menanggung beban. Mereka diberikan codebase yang rapuh dan diminta untuk menskalakannya. Tapi membangun ulang? Itu bukan pilihan. Tidak ada anggaran untuk itu. Tidak ada waktu. Tidak ada dukungan dari pemangku kepentingan. Jadi, pengembang terus bekerja, menambal masalah kecil dengan solusi yang tidak permanen, hingga akhirnya perubahan kecil saja bisa menyebabkan kerusakan besar pada sistem.
Pendekatan ini seolah-olah memisahkan "pembangunan produk" dan "pemeliharaan produk" menjadi dua dunia yang terpisah. Namun kenyataannya, maintenance dan development harus berjalan beriringan. Menunda maintenance dengan harapan sistem akan tetap berjalan hanya akan memperburuk keadaan di masa depan.
Ironi dari Ketimpangan *Maintenance*
Sebagian besar umur perangkat lunak dihabiskan dalam fase maintenance. Bukan saat peluncuran atau pengembangan fitur besar yang menentukan keberhasilan---melainkan masa-masa yang sunyi dan penuh tantangan setelahnya, ketika perangkat lunak perlu dirawat, disesuaikan, dan tetap berjalan dengan stabil. Namun, banyak organisasi yang justru memperlakukan fase ini seperti hal yang tidak penting, dan anggaran sering kali dialokasikan lebih banyak untuk fase pengembangan daripada untuk maintenance.
