Software Hebat Butuh Waktu, Tidak Bisa Dipaksa Cepat

Flask butuh delapan tahun untuk mencapai versi 1.0. SQLite sudah dikembangkan secara aktif sejak tahun 2000 dan masih terus mendapat peningkatan yang berarti. Kernel Linux sudah berusia lebih dari tiga dekade dan bisa dibilang makin baik seiring waktu. Sementara itu, rata-rata startup yang didanai VC diharapkan sudah menunjukkan traksi dalam 18 bulan, atau harus menjelaskan kenapa belum.

Ada kesenjangan yang makin lebar antara berapa lama software yang bagus sebenarnya dibangun dan berapa lama kita berharap itu selesai. Tekanan untuk segera rilis sebenarnya tidak salah, tapi tekanan itu menciptakan budaya di mana kesabaran dianggap kurang ambisi, dan proyek-proyek yang bertahan lama justru dicap "lambat" selama bertahun-tahun ketika mereka diam-diam sedang membenahi hal yang benar.

Mitos Kesuksesan Semalam

Hampir setiap "kesuksesan semalam" di dunia software punya latar belakang yang panjang. React sudah dipakai secara internal di Facebook selama lebih dari setahun sebelum di-open source. Rust menghabiskan tujuh tahun dalam pengembangan sebelum mencapai 1.0. PostgreSQL dimulai sebagai proyek riset pada 1986 dan baru menjadi database produksi pilihan utama di tahun 2010-an, hampir 30 tahun perbaikan yang tenang dan stabil.

Yang tampak seperti kemunculan mendadak biasanya adalah hasil dari peningkatan yang terakumulasi hingga melewati ambang keterlihatan. Software itu terus membaik sepanjang waktu. Orang-orang saja yang belum memperhatikan sampai akhirnya ia menjadi cukup bagus untuk tidak bisa diabaikan.

Armin Ronacher, pembuat Flask, menulis tentang hal ini secara langsung. Flask dimulai sebagai lelucon April Fools pada 2010. Ia menjadi proyek serius hampir tanpa disengaja. Bertahun-tahun kerja bertahap, seperti memperbaiki edge case, meningkatkan dokumentasi, dan merancang ulang API, mengubahnya menjadi salah satu framework web Python paling populer. Tidak ada satu pun tahun itu yang terbuang. Setiap tahun membuat fondasinya makin kuat.

Mengapa Software Punya Komponen Waktu yang Tak Bisa Dihilangkan

Ada beberapa masalah yang tidak bisa diselesaikan lebih cepat dengan menambah orang atau bekerja lebih keras. Fred Brooks mengidentifikasi hal ini pada 1975 lewat The Mythical Man-Month, dan inti pemikirannya belum berubah: beberapa aspek pengembangan software bersifat sekuensial, tidak bisa diparalelkan.

• Memahami domain masalah. Kamu tidak benar-benar memahami sebuah ruang masalah sebelum hidup di dalamnya cukup lama. Versi pertama software apa pun merekam asumsi awalmu. Versi kedua merekam apa yang kamu pelajari dari versi pertama. Pemahaman yang sungguh-sungguh butuh iterasi, dan iterasi butuh waktu.
• Desain dan stabilitas API. API yang bagus lahir dari pemakaian. Kamu tidak bisa merancang API yang sempurna di ruang hampa. Kamu butuh pengguna sungguhan yang menemukan edge case sungguhan. Library yang terburu-buru mencapai 1.0 sering menyesali keputusan desain awalnya selama bertahun-tahun.
• Edge case dan pengerasan. 80% pertama dari sebuah fitur memakan 20% waktu. Sisa edge case, penanganan error, dan keanehan platform memakan 80% waktu lainnya. Rasio ini bukan karena kemalasan, melainkan sifat dasar dari membuat software yang andal.
• Komunitas dan ekosistem. Sebuah tool belum benar-benar berguna sampai ia punya dokumentasi, tutorial, plugin, dan komunitas yang menjawab pertanyaan. Ekosistem ini tidak bisa dibuat secara instan; ia tumbuh secara organik seiring waktu.

Dampak Tekanan Waktu yang Dibuat-buat

"Move fast and break things" adalah motto yang masuk akal untuk jejaring sosial yang sedang mencari product-market fit. Tapi itu filosofi yang buruk untuk infrastruktur, tool developer, database, atau apa pun yang menjadi sandaran sistem orang lain. Ketika software fondasi dikejar-kejar, kerusakannya menumpuk.

Saya sudah menyaksikan beberapa proyek open source yang menjanjikan runtuh karena mencoba tumbuh lebih cepat daripada kemampuan fondasinya. Polanya bisa ditebak: proyek jadi populer, maintainer merasa tertekan untuk merilis fitur dengan cepat, kualitas turun, kontributor kelelahan, dan pengguna pindah ke sesuatu yang lebih stabil. Ironisnya, memperlambat langkah justru bisa membawa mereka lebih jauh.

Proyek yang bertahan bukanlah yang paling cepat merilis. Mereka adalah yang membuat keputusan baik cukup dini sehingga tidak perlu menulis ulang semuanya di kemudian hari.

Utang teknis bukan cuma soal kode yang berantakan. Ini tentang keputusan yang diambil di bawah tekanan waktu yang membatasi kemungkinan di masa depan. Setiap jalan pintas untuk merilis lebih cepat adalah pajak atas setiap perubahan berikutnya. Beberapa jalan pintas memang layak diambil, tapi ambillah dengan sadar, bukan karena seseorang tiba-tiba memutuskan deadline-nya hari Selasa depan.

Seperti Apa Kesabaran dalam Praktik

Kesabaran dalam pengembangan software bukan berarti bergerak lambat tanpa alasan. Artinya bersikap sengaja tentang apa yang kamu bangun dan jujur tentang berapa lama sesuatu benar-benar butuh waktu. Beberapa pola yang menurut saya berhasil dengan baik:

• Rilis cepat, tapi berkomitmen perlahan. Rilis software kamu ke pengguna dengan cepat supaya dapat feedback, tapi sangat konservatif tentang apa yang kamu janjikan sebagai API stabil. Gunakan versioning 0.x dengan murah hati. Pastikan jelas bahwa segalanya mungkin berubah.
• Katakan tidak pada fitur. Setiap fitur yang kamu tambahkan adalah fitur yang harus kamu rawat selamanya. Proyek terbaik punya pendirian yang kuat soal cakupannya. SQLite secara eksplisit mencantumkan hal-hal yang tidak akan pernah dilakukannya, dan disiplin itulah alasan ia menjadi database paling banyak dipakai di dunia.
• Investasikan pada fondasi. Dokumentasi, testing, pesan error, performa. Ini memang tidak glamor, tapi dampaknya terakumulasi. Proyek yang terdokumentasi baik dengan suite test yang solid bisa bergerak lebih cepat di tahun ketiga dibanding proyek yang berantakan di tahun pertama.
• Lindungi energi maintainer. Burnout adalah pembunuh nomor satu proyek open source. Ritme yang berkelanjutan lebih penting daripada velocity sprint. Maintainer yang bekerja 20 jam fokus per minggu selama lima tahun akan menghasilkan lebih banyak daripada yang bekerja 80 jam per minggu selama enam bulan lalu menghilang.

Jebakan Kecepatan Startup

Startup menghadapi ketegangan yang nyata: mereka perlu bergerak cepat untuk bertahan, tapi bergerak terlalu cepat menciptakan sistem rapuh yang menjadi beban saat skala membesar. Perusahaan yang berhasil melewatinya cenderung membedakan dua jenis kecepatan.

Kecepatan iterasi — seberapa cepat kamu bisa menguji ide, mendapatkan feedback pengguna, dan mengubah arah. Ini sebaiknya dimaksimalkan. Siklus pendek, prototyping cepat, dan kemauan untuk membuang sesuatu.

Kecepatan komitmen — seberapa cepat kamu mengunci keputusan arsitektur, API publik, dan model data. Ini sebaiknya diminimalkan. Jaga agar segalanya tetap bisa dibalik selama mungkin. Semakin lama kamu menunda keputusan yang tidak bisa dibalik, semakin banyak informasi yang kamu punya saat akhirnya harus memutuskan.

Kesalahan yang paling sering dilakukan startup adalah mencampuradukkan keduanya. Mereka berkomitmen pada arsitektur secepat mereka mengiterasi fitur, lalu menghabiskan dua tahun berikutnya membayar pajak atas keputusan prematur.

Belajar dari Proyek yang Bertahan

Proyek software yang paling sering kita andalkan punya satu kesamaan: pada suatu waktu, semuanya dianggap "lambat". PostgreSQL adalah pilihan yang membosankan, sementara MySQL adalah opsi cepat dan serampangan. Python dianggap "terlalu lambat" sementara Perl adalah pilihan yang pragmatis. Git butuh bertahun-tahun sebelum bisa dipakai manusia biasa.

Yang dimiliki proyek-proyek ini adalah waktu: waktu untuk membuat kesalahan, belajar darinya, dan membangun sesuatu yang kokoh. Mereka tidak berusaha menjadi segalanya untuk semua orang di tahun pertama. Mereka berusaha unggul di tujuan intinya, dan mereka rela membiarkan keunggulan itu butuh waktu sebanyak yang diperlukan.

Lain kali kamu kesal karena sebuah proyek "terlalu lama", ingatlah bahwa hal-hal yang paling kamu andalkan, seperti sistem operasi, database, runtime bahasa, dan version control, semuanya butuh waktu lebih lama dari yang diperkirakan siapa pun. Dan itulah alasan persisnya mengapa mereka berfungsi.

Ada hal-hal yang memang butuh waktu. Respons terbaik bukan melawan kenyataan itu, melainkan membangun sistem, tim, dan ekspektasi yang memperhitungkannya.