Cargo Cult Development: Meniru Big Tech Tanpa Konteks

Bayangkan seorang petani di pedalaman Papua Nugini pada 1940-an. Ia melihat pesawat tempur Amerika mendarat di lapangan darurat, membawa makanan, alat komunikasi, dan perlengkapan medis. Setelah perang usai dan pesawat tak pernah kembali, para suku tersebut membangun landasan pacu dari kayu, meniru bentuk menara pengawas dari bambu, dan mengenakan penutup kepala yang menyerupai headset radio. Mereka melakukan segalanya dengan tepat, kecuali satu hal yang paling penting: memahami mengapa ritual itu bekerja.

Delapan dekade kemudian, fenomena serupa terjadi di dunia teknologi. Hanya saja kali ini, landasan pacu kayu itu bernama microservices. Menara bambunya adalah Kubernetes. Dan headset radionya adalah event sourcing yang diimplementasikan untuk aplikasi todo list dengan tiga pengguna aktif. Kita semua, pada titik tertentu, pernah menjadi bagian dari cargo cult development: meniru praktik engineering kelas dunia tanpa memahami konteks yang membuat praktik itu relevan.

Dari Militer ke Monorepo: Sejarah Cargo Cult

Istilah cargo cult pertama kali digunakan antropolog untuk menjelaskan gerakan keagamaan di Melanesia pasca-Perang Dunia II. Para penganutnya meniru ritual militer dengan harapan pesawat kargo akan kembali membawa kekayaan. Ritual itu tampak benar secara visual, tapi sepenuhnya kosong secara fungsional karena mereka tidak mengerti teknologi radar, logistik, atau rantai pasok militer.

Di software engineering, konsep serupa diperkenalkan secara luas oleh Eric Lippert dan kemudian dipopulerkan dalam diskusi komunitas developer. Cargo cult programming terjadi ketika engineer menulis kode yang menyerupai pola yang pernah dilihatnya, tanpa memahami mengapa pola itu ada atau kapan ia seharusnya digunakan. Bukan sekadar copy-paste dari Stack Overflow. Ini adalah copy-paste arsitektur dari whitepaper Google.

Microservices untuk Tim Tiga Orang

Puncak cargo cult modern mungkin terjadi sekitar 2015-2020, ketika setiap startup yang baru menerima seed funding langsung membagi codebase mereka menjadi dua belas layanan kecil. Alasannya sederhana: Netflix melakukannya. Uber melakukannya. Amazon melakukannya. Jika perusahaan bernilai miliaran dolar menggunakan arsitektur terdistribusi, maka startup kami yang baru berusia enam bulan pasti membutuhkannya juga.

Masalahnya: microservices adalah solusi untuk masalah skala organisasi, bukan masalah skala teknis. Martin Fowler sendiri, yang ikut mempopulerkan pola ini, secara eksplisit menyatakan bahwa microservices meningkatkan kompleksitas secara dramatis dan sebaiknya dihindari hingga tim cukup besar untuk membenarkan overhead komunikasi antar-tim. Startup dengan lima engineer yang memecah monolitik mereka menjadi 15 layanan tidak sedang membangun sistem yang scalable. Mereka sedang membangun 15 sistem yang gagal secara independen.

Dan ini bukan hipotesis. ThoughtWorks telah berulang kali mendokumentasikan bagaimana klien mereka menemukan bahwa monolitik yang dirapikan sering kali memberikan throughput dan keandalan yang lebih baik daripada orkestrasi layanan yang rapuh, terutama pada skala kecil hingga menengah.

Kubernetes untuk Static Blog

Jika microservices adalah landasan pacu kayu, maka Kubernetes adalah menara pengawas dari bambu. Platform orkestrasi ini memang luar biasa: auto-scaling, self-healing, declarative deployment. Tapi kemampuan tersebut datang dengan biaya kognitif yang sangat tinggi. Sebuah tim harus mempekerjakan satu atau dua engineer hanya untuk memelihara cluster, belajar konsep seperti ingress controller, persistent volume, dan service mesh.

Dan untuk apa? Menjalankan tiga container yang sebenarnya bisa dihosting dengan baik di platform managed seperti Heroku, Railway, atau Vercel. Dan McKinley dalam esai klasiknya "Choose Boring Technology" berargumen bahwa setiap organisasi memiliki anggaran inovasi yang terbatas. Jika Anda menghabiskan anggaran tersebut pada infrastruktur yang belum Anda butuhkan, Anda kehilangan kesempatan untuk berinovasi pada produk itu sendiri. Kubernetes bukanlah teknologi yang buruk. Ia hanyalah teknologi yang salah untuk sebagian besar konteks.

Event Sourcing, CQRS, dan Resume-Driven Development

Bukan hanya infrastruktur. Di level aplikasi, kita melihat pola serupa. Event sourcing dipilih karena terdengar enterprise. CQRS dipilih karena terdengar canggih. GraphQL dipilih karena REST terasa ketinggalan zaman, meskipun 90% endpoint hanya melakukan CRUD sederhana yang jauh lebih ekspresif dan cacheable dengan REST.

Phin Barnes, partner di First Round Capital, pernah mengamati bahwa teknologi pilihan sering kali menjadi signaling mechanism dalam industri ini. Developer memilih teknologi yang akan terlihat mengesankan di LinkedIn, bukan yang akan menyelesaikan masalah pengguna dengan paling sedikit baris kode. Ini adalah resume-driven development: arsitektur yang dirancang untuk portofolio, bukan untuk produk.

Dan hasilnya prediktabil. Waktu development melambat karena setiap fitur sederhana harus menyeberangi tiga lapisan abstraksi. Onboarding engineer baru membutuhkan enam bulan karena domain knowledge tersebar di selusin repository. Debugging menjadi mimpi buruk karena satu request user menghasilkan jejak log di lima layanan berbeda. Tim tidak sedang bergerak cepat. Mereka sedang bergerak lambat dengan banyak langkah.

Kenapa Kita Terus Melakukannya

Jika cargo cult development begitu jelas merugikan, mengapa ia terus berulang? Ada setidaknya tiga alasan psikologis.

Pertama, availability heuristic. Kita melihat studi kasus sukses dari perusahaan besar yang menggunakan teknologi X, dan berasumsi bahwa teknologi X menyebabkan kesuksesan mereka. Padahal korelasi bukan kausalitas. Amazon sukses bukan karena microservices. Mereka menggunakan microservices karena mereka sudah sukses dan besar.

Kedua, fear of missing out. Industri teknologi bergerak dengan kecepatan yang membuat setiap orang merasa sedang tertinggal. Jika semua orang di Hacker News membahas service mesh, rasanya bodoh untuk tidak mengadopsinya. Padahal Hacker News bukan representasi dari kebutuhan bisnis Anda. Ia adalah representasi dari apa yang menarik bagi engineer yang suka membaca tentang teknologi baru.

Ketiga, dan yang paling fundamental, keinginan manusia untuk ritual. Ritual memberikan rasa kontrol dalam dunia yang kompleks dan tidak pasti. Menulis file YAML Kubernetes yang rumit terasa seperti melakukan sesuatu yang penting, meskipun pada kenyataannya Anda baru saja menambahkan dua minggu latensi pada deployment fitur tombol baru.

Antidot: Konteks di Atas Konvensi

Jadi apa solusinya? Apakah kita harus menolak semua teknologi baru dan kembali ke PHP monolitik di shared hosting? Tentu tidak. Solusinya adalah bukan tentang teknologi mana yang dipilih, melainkan tentang proses pemilihannya.

Mulailah dengan masalah, bukan solusi. Sebelum memilih arsitektur, tuliskan constraint nyata: berapa request per detik yang Anda harapkan dalam 12 bulan? Berapa besar tim engineering Anda? Apa yang paling sering berubah: skema data, logika bisnis, atau antarmuka pengguna?

Pelajari prinsip, bukan produk. Jika Anda memahami mengapa eventual consistency diperlukan dalam sistem distributed, Anda tidak akan terpikat untuk mengimplementasikan event sourcing hanya karena terdengar keren. Anda akan mengimplementasikannya ketika konsistensi kuat benar-benar menjadi bottleneck yang terukur.

Dan terakhir, terapkan YAGNI secara agresif. You Ain't Gonna Need It bukanlah sikap anti-teknologi. Ia adalah sikap pro-kefokusan. Setiap baris kode yang Anda tulis adalah beban. Setiap layanan yang Anda deploy adalah beban. Setiap abstraksi yang Anda perkenalkan adalah beban. Teknologi seharusnya mengurangi beban, bukan menambahkannya.

Pertanyaan yang Belum Terjawab

Cargo cult development tidak akan hilang. Ia adalah manifestasi dari kecemasan dan aspirasi manusia dalam bentuk yang sangat teknis. Tapi mungkin ada satu pertanyaan yang lebih penting dari sekadar "teknologi apa yang harus saya pilih". Yaitu: apakah tim Anda cukup aman untuk mengakui bahwa pilihan teknologi sebelumnya mungkin salah?

Karena pada akhirnya, landasan pacu dari kayu tidak gagal karena kayunya buruk. Ia gagal karena yang membangunnya tidak pernah bertanya: untuk apa sebenarnya pesawat ini datang?