Mitos Kecepatan: Mengapa Perangkat Lunak Terbaik Adalah yang Dibuat dengan Tidak Tergesa-gesa

Kapan terakhir kali kamu merasa bangga dengan kode yang ditulis dalam semalam? Bukan karena berhasil merge sebelum deadline, tapi karena kode itu terasa benar: mudah dibaca, tepat sasaran, dan tahan lama. Jujur saja, momen seperti itu semakin jarang di era di mana velocity diukur setiap sprint, framework baru lahir tiap quarter, dan ungkapan "move fast and break things" masih dianggap motto keren.

Kita sudah terjebak dalam mitos kecepatan. Mitos yang mengatakan semakin cepat kita mengirimkan fitur, semakin baik. Semakin banyak library yang kita tumpuk, semakin canggih. Semakin sedikit tidur yang kita butuhkan demi push kode, semakin dedicated. Padahal, dari sudut pandang systems design, kecepatan tanpa arah bukanlah produktivitas: itu adalah technical debt yang belum menyadari dirinya sendiri.

Kultus Kecepatan dan Harga yang Tidak Terlihat

Silicon Valley telah menjual narasi bahwa disruptor adalah yang paling cepat. Startup yang meluncurkan MVP dalam dua minggu dipuja. Engineer yang commit ratusan baris kode sehari dipromosikan. Tapi kita jarang ditanya: berapa banyak dari kode itu yang benar-benar bertahan tiga tahun? Berapa banyak meeting yang terpaksa diadakan karena arsitektur dasar yang dipilih dalam tergesa-gesa kini mulai retak?

Tanya Reilly, dalam talk fenomenalnya Being Glue, mengingatkan kita bahwa ada pekerjaan penting yang tidak terlihat dalam velocity chart: onboarding engineer junior, memperbarui roadmap, meninjau desain, dan memastikan tim tidak berjalan ke arah berbeda. Pekerjaan ini bukanlah penghambat kecepatan. Ini adalah infrastruktur sosial yang membuat kecepatan menjadi mungkin. Tanpa glue work, yang terjadi bukanlah iterasi cepat, tapi chaos terorganisir.

Avery Pennarun, dalam tulisannya Systems Design Explains the World, membedah fenomena yang sama dari sudut sistem. Ia menunjukkan bahwa banyak engineer hebat justru terjebak di level senior karena mereka terlalu mahir melakukan glue work, sementara rekan-rekan yang menulis kode lebih cepat naik pangkat lebih dulu. Paradoksnya: perusahaan mempromosikan kecepatan, tapi kemudian kekurangan orang-orang yang bisa mencegah sistem dari keruntuhan jangka panjang.

Boring is Beautiful

Dan McKinley, mantan engineer Etsy, pernah mengusulkan konsep yang kini menjadi klasik: Choose Boring Technology. Setiap perusahaan, katanya, hanya punya sekitar tiga token inovasi. Jika kamu menghabiskannya untuk teknologi yang masih berkedip-kedip baru, maka kamu tidak punya sisa energi untuk inovasi di domain bisnismu sendiri.

MySQL membosankan. Postgres membosankan. Python membosankan. Cron membosankan. Tapi membosankan dalam konteks ini bukan berarti buruk. Artinya, failure mode-nya sudah dipahami dunia. Artinya, ketika ada incident pukul dua pagi, kamu tidak sedang membaca dokumentasi versi 0.3 yang masih penuh todo. Artinya, timmu bisa fokus memecahkan masalah pengguna, bukan masalah garbage collector.

Memilih teknologi yang membosankan adalah tindakan resistensi. Resistensi terhadap hype. Resistensi terhadap FOMO yang dibuat oleh konferensi teknologi dan thread Twitter panjang. Ini adalah keputusan filosofis: kita percaya bahwa software yang baik lahir dari pemahaman mendalam, bukan dari eksperimen berdarah-darah di production.

Craftsmanship dan Nilai yang Bertambah Secara Stabil

Manifesto for Software Craftsmanship menyatakan sesuatu yang terdengar radikal di tengah budaya sprint: kita tidak hanya menghargai software yang bekerja, tapi juga software yang well-crafted. Kita tidak hanya merespons perubahan, tapi juga menambah nilai secara stabil.

Kata kunci di sini adalah steadily. Bukan cepat. Banyak. Atau spektakuler. Tapi stabil, konsisten, dan berkelanjutan. Seperti seorang pengrajin kayu yang menghabiskan hari untuk menyempurnakan sendi satu meja, engineer sejati tahu bahwa refactoring satu modul yang membingungkan bisa memberikan dampak lebih besar bagi produktivitas tim dibanding menambahkan tiga endpoint baru.

Budaya kecepatan justru sering menghukum pekerjaan semacam ini. Refactoring tidak punya story point yang menarik di demo. Memperbaiki dokumentasi tidak masuk dalam changelog yang bombastis. Menyetel monitoring tidak seksexi merilis fitur AI. Padahal, semua pekerjaan "lambat" inilah yang membedakan software yang bisa diskalakan dari software yang akan diganti dalam dua tahun karena tech debt-nya sudah tidak terawat.

Yang ironis, semakin sering kita mengabaikan pekerjaan tak terlihat ini, semakin sering kita kemudian harus melakukan pekerjaan darurat yang justru lebih melambatkan roadmap. Technical debt yang dibiarkan bukanlah masalah masa depan. Ia adalah pajak bunga yang kita bayar setiap hari dalam bentuk waktu debug yang lebih lama, onboarding yang lebih sulit, dan keputusan arsitektur yang semakin terbatas.

Resistensi sebagai Etika Engineering

Di titik ini, menolak kecepatan demi kecepatan bukanlah sikap defensif: itu adalah etika. Ketika product manager menekan untuk fitur yang belum matang, ketika CTO ingin migrasi ke database yang baru rilis alpha, ketika investor menuntut demo yang mengkilap, engineer yang berpengalaman punya tanggung jawab untuk mengatakan: tidak sekarang.

Menolak bukan berarti memblokir. Ini berarti menuntut argumentasi yang lebih dalam. Ini berarti mempertanyakan apakah masalah yang hendak dipecahkan sudah cukup dipahami. Ini berarti mengakui bahwa software adalah sistem kompleks, bukan assembly line di mana menambahkan tenaga kerja secara otomatis mempercepat output.

Kita sering lupa bahwa Brooks Law sudah dipublikasikan lebih dari setengah abad yang lalu: menambah orang ke proyek software yang terlambat justru membuatnya semakin terlambat. Logika ini berlaku juga untuk teknologi. Menambahkan framework baru, bahasa baru, atau paradigma baru ke dalam stack yang sedang kritis tidak akan mempercepat apa pun. Ia hanya menambah surface area untuk kesalahan.

Ke Mana Kita Melangkah?

Industri kita tidak akan melambat secara keseluruhan. Ada pasar, ada kompetisi, ada ekspektasi pengguna. Tapi kita, sebagai individu dan sebagai tim, punya pilihan. Kita bisa memilih untuk tidak ikut dalam lomba kecepatan yang tidak punya garis finis. Kita bisa memilih untuk mengukur diri kita bukan dari berapa banyak PR yang merge, tapi dari seberapa sedikit bug yang muncul enam bulan kemudian. Kita bisa memilih untuk menjadi pengrajin, bukan assembly worker.

Perangkat lunak terbaik yang pernah kamu gunakan kemungkinan besar tidak dibuat dalam sprint yang dipaksakan. Ia dibuat oleh orang-orang yang memahami bahwa ketekunan mengalahkan kecepatan, bahwa kesederhanaan mengalahkan kompleksitas, dan bahwa kerja yang tidak terlihat sering kali adalah yang paling bernilai.

Maka, pertanyaannya bukan: seberapa cepat kamu bisa mengirimkan fitur berikutnya? Melainkan: apakah fitur itu akan bertahan cukup lama untuk membuat bangga engineer yang memeliharanya lima tahun mendatang?