Setiap tim teknik memiliki anggaran inovasi yang tetap. Bukan anggaran dalam rupiah, anggaran yang menjadi perhatian: berapa banyak hal baru yang belum terbukti dapat diserap tim sebelum ada yang rusak dan tidak ada yang tahu alasannya. Tim yang menang bukanlah tim yang menghabiskan anggaran tersebut untuk tumpukan paling trendi. Merekalah yang membelanjakannya untuk satu atau dua hal yang benar-benar membedakan produk, dan membeli teknologi yang membosankan untuk hal lainnya.

Saya telah menyaksikan hal ini terjadi selama satu dekade kerja klien, mulai dari platform dengan 656.000 pengguna hingga sistem keuangan perusahaan yang masih berjalan hingga saat ini. Polanya berulang: proyek yang tetap tenang pada jam 3 pagi adalah proyek yang dibangun di atas database dan kerangka kerja yang sudah berkali-kali gagal di depan umum, jadi semua orang sudah tahu cara memperbaikinya.

Teknologi yang membosankan bukan berarti kurangnya ambisi. Di situlah Anda memilih untuk mengambil risiko.

Apa sebenarnya arti "membosankan".

Membosankan bukan berarti tua demi hal itu sendiri. Artinya mode kegagalan diketahui. PostgreSQL telah melakukan terobosan dengan cara yang terdokumentasi sejak tahun 1990an. Pencarian Stack Overflow atau pesan Slack dua baris ke teknisi lain biasanya menyelesaikannya dalam hitungan menit. Bandingkan dengan database vektor baru atau kerangka kerja yang dikirimkan enam bulan lalu: ketika rusak pada jam 2 pagi, Anda membaca terbitan GitHub dari tiga minggu lalu dengan harapan orang lain mengalami masalah yang sama.

Teknologi yang membosankan memiliki tiga sifat yang patut disebutkan:

  • Mode kegagalan yang diketahui. Orang-orang telah menemukan kasus edge, sehingga internet telah menulis perbaikannya.
  • Kumpulan perekrutan yang mendalam. Anda dapat menemukan insinyur yang menguasai PHP, Node, atau .NET dalam seminggu. Anda tidak selalu dapat menemukan orang yang mengetahui kerangka kerja yang mencapai puncaknya di Hacker News pada kuartal terakhir.
  • Cakrawala dukungan yang panjang. Alat yang membosankan dipertahankan selama satu dekade, tidak ditinggalkan setelah pengelolanya melanjutkan.

Semua ini tidak menarik untuk dibicarakan saat pertemuan. Itulah alasan mengapa ini berfungsi untuk sistem penggajian, platform inventaris, dan apa pun yang benar-benar diandalkan oleh bisnis untuk dijalankan.

Ke mana anggaran inovasi harus disalurkan

Saya tidak menentang teknologi baru. Saya berdebat tentang penempatan. Jika Anda membangun aplikasi pengumpulan fintech, logika pendeteksi penipuan, mesin penetapan harga, atau pengalaman pelanggan spesifik yang membuat produk Anda lebih baik daripada produk pesaing, di situlah pilihan baru menghasilkan risiko. Basis data di bawahnya, lapisan autentikasi, antrian pekerjaan, alur penerapan: semua itu tidak perlu menarik. Itu harus benar dan dapat dilupakan.

Sebuah perusahaan multifinance tempat saya bekerja ingin memodernisasi sistem penagihan pinjaman mereka. Tekanan internal adalah mengejar mesin rekomendasi terbaru dan alat alur kerja tanpa kode yang trendi, karena pesaing telah mengumumkan hal serupa. Kami menghabiskan anggaran inovasi sebenarnya untuk logika penentuan prioritas pengumpulan, bagian yang berhubungan langsung dengan pendapatan. Infrastruktur di bawahnya (database relasional, REST API standar, backend .NET yang matang) sengaja dibuat tidak menarik. Delapan belas bulan kemudian, tidak ada lagi insiden infrastruktur yang terjadi pada sistem ini. Semua bug yang menarik, dan ada beberapa, muncul dalam logika bisnis yang kami pilih untuk berinovasi, tepat di tempat yang ingin kami debug.

Biaya yang semakin besar dari pilihan-pilihan yang menarikTeknologi yang menarik memiliki kurva biaya yang tidak terlihat pada bulan pertama dan sangat brutal pada tahun kedua. Kerangka kerja dengan komunitas kecil berarti setiap bug yang tidak sepele menjadi proyek penelitian. Basis data dengan peralatan yang belum matang berarti kisah pencadangan dan migrasi Anda diimprovisasi, bukan diuji coba. Dan ketika insinyur asli yang memilih alat menarik tersebut keluar, dan mereka akhirnya melakukannya, penggantinya mewarisi sistem yang tidak sepenuhnya dipahami oleh orang lain di pasar.

Saya telah melihat kegagalan seperti ini pada jaringan ritel di Tangerang yang mengadopsi platform perdagangan tanpa kepala (niche headless commerce) pada tahun 2021 karena menjanjikan kecepatan. Pada tahun 2024, vendor telah memutar model bisnis sebanyak dua kali, dokumentasi telah membusuk, dan satu-satunya pengembang yang memahami keunikan tersebut telah pindah. Mereka akhirnya membangun kembali tumpukan e-commerce standar yang membosankan, dengan biaya yang jauh lebih tinggi dibandingkan jika mereka memilih yang membosankan sejak hari pertama. Ini adalah jebakan yang sama yang tercakup dalam mengapa perkiraan perangkat lunak selalu salah: perkiraan tersebut tidak pernah memperhitungkan pajak atas hal-hal baru yang bertambah secara diam-diam di latar belakang.

Tes sederhana sebelum mengadopsi sesuatu yang baru

Sebelum memberi lampu hijau pada alat, database, atau kerangka kerja baru untuk sistem bisnis inti, saya mengajukan tiga pertanyaan:

  1. Apakah ini sudah gagal di publik? Jika tidak ada yang menulis hasil otopsi tentang hal ini, Anda akan menulis yang pertama.
  2. Dapatkah saya menyewa pekerjaan ini dalam waktu kurang dari sebulan? Jika jawabannya tidak, Anda sedang membangun ketergantungan pada satu orang.
  3. Apakah ini menyentuh bagian produk yang menghasilkan uang, atau pipa ledeng di bawahnya? Pipa mempunyai pilihan yang membosankan. Logika yang berorientasi pada pendapatan dapat mengambil lebih banyak risiko.

Jika suatu alat gagal ketiganya, itu adalah pilihan prototipe, bukan pilihan produksi. Simpan di proyek sampingan, bukan di sistem yang menjalankan penggajian.

Teknologi yang membosankan sebagai keputusan kepemimpinan

Ini sebenarnya bukan panggilan teknik, ini adalah panggilan kepemimpinan, dan ini adalah panggilan yang saya buat secara eksplisit dengan setiap tim tempat saya bekerja, baik sebagai CTO penuh waktu atau dalam kapasitas [mitra teknologi fraksional] (/blog/full-time-cto-vs-fractional-tech-partner). Insinyur junior ingin menggunakan hal terbaru karena ini adalah baris resume. Insinyur senior yang telah dihubungi pada jam 3 pagi menginginkan alat yang gagal seperti yang pernah mereka lihat. Bagian dari tugasnya adalah melindungi sistem dari naluri pertama dan mengarahkan energi tim ke naluri kedua.

Bisnis yang melakukan hal ini dengan benar tidak terlihat mengesankan dalam postingan blog teknologi. Tumpukan mereka biasa-biasa saja. Yang luar biasa adalah sistem mereka terus berjalan, tahun demi tahun, sementara para pesaing yang mengejar tumpukan yang menarik masih berjuang melawan pilihan yang dibuat dua tahun lalu.

Kesimpulannya

Habiskan anggaran inovasi Anda untuk hal-hal yang membuat produk Anda berbeda, bukan untuk hal-hal yang membuat produk Anda tetap berjalan. Pilih database, kerangka kerja, dan infrastruktur dengan mode kegagalan yang sudah dipahami seluruh industri, dan simpan risiko menarik untuk logika yang benar-benar menghasilkan pendapatan. Membosankan bukanlah tidak adanya ambisi. Di situlah ambisi seharusnya tidak terjadi.