Memuja Kompleksitas: Mengapa Developer Membuat Hidup Sulit

Ada sebuah kejanggalan yang jarang dibahas di komunitas teknologi: semakin canggih alat yang kita miliki, semakin rumit pula arsitektur yang kita bangun. Padahal, bisnis yang sama seringkali bisa dijalankan dengan seperangkat kode yang jauh lebih sederhana. Fenomena ini bukan sekadar masalah teknis. Ini adalah masalah psikologis, bahkan hampir seperti bentuk fanatisme modern yang menyelimuti industri kita.

Saya teringat tulisan legendaris dari Dan Luu yang berjudul In Defense of Simple Architectures. Di sana ia menjabarkan bagaimana Wave, perusahaan fintech Afrika senilai 1,7 miliar dolar dengan 70 engineer, menjalankan operasinya di atas sebuah Python monolith yang sangat biasa. Tidak ada mikroservis yang mempesona, tidak ada orkestrasi yang bikin pusing, hanya Python dan Postgres yang bekerja secara sinkron. Dan itu cukup. Bahkan lebih dari cukup.

Stack Overflow, yang dibangun di atas monolith .NET dan SQL Server, juga membuktikan hal serupa. Mereka menangani traffic situs top-100 global tanpa perlu arsitektur yang terlihat seperti peta bintang dari film fiksi ilmiah. Jika Wave dan Stack Overflow bisa mencapai skala besar dengan pendekatan yang membosankan, lalu mengapa kita, developer di startup dengan traffic yang jauh lebih kecil, justru terobsesi pada kompleksitas yang seringkali tidak kita butuhkan?

Kecanduan pada Kerumitan

Salah satu jawabannya terletak pada apa yang bisa kita sebut complexity bias: kecenderungan manusia untuk menganggap sesuatu yang rumit itu lebih canggih, lebih pintar, dan lebih berharga. Dalam dunia software, kerumitan sering disalahartikan sebagai kedalaman keilmuan. Developer yang membangun pipeline Kubernetes dengan dua puluh service mesh dianggap "senior", sementara yang memelihara monolith Ruby on Rails dengan hati-hati dianggap "ketinggalan zaman".

Tahun 1989, Richard Gabriel menulis esai yang kini legendaris: The Rise of Worse is Better. Ia membandingkan filosofi desain Lisp yang idealis dan sempurna dengan pendekatan Unix dan C yang secara teknis lebih buruk, tetapi lebih sederhana dan lebih mudah disebarkan. Hasilnya? Yang "lebih buruk" justru memenangkan pasar. Bukan karena lebih baik secara teknis, tetapi karena lebih pragmatis, lebih mudah dipahami, dan lebih cepat diadopsi.

Gabriel kemudian mengakui bahwa ia sendiri sempat tidak nyaman dengan gagasan ini. Bagaimana mungkin sesuatu yang "lebih buruk" bisa lebih baik? Jawabannya adalah: software tidak hidup di ruang vakum akademis. Software hidup di tangan manusia yang harus memeliharanya, memperbaikinya, dan memahaminya saat tengah malam ketika production down dan semua orang panik.

Konferensi dan Kultura Kompleksitas

Dan Luu mencatat sebuah observasi yang menarik dari sebuah konferensi teknologi umum: ada enam talk tentang cara menangani efek samping arsitektur mikroservis yang rumit, dan nol talk tentang cara membangun monolith yang sederhana. Bahkan, talk tentang komputasi kuantum lebih banyak daripada talk tentang monolith. Di konferensi enterprise di San Francisco, jumlah talk tentang menangani kompleksitas arsitektur canggih mencapai dua digit, sementara talk tentang monolith: nol.

Ini menciptakan selection bias yang berbahaya. Developer yang menghadiri konferensi pulang dengan keyakinan bahwa arsitektur "modern" harus kompleks. Mereka lalu mengimplementasikan sistem terdistribusi di perusahaan dengan skala rendah, hanya karena itu terdengar lebih canggih di LinkedIn. Kompleksitas bukan lagi solusi untuk masalah, melainkan tujuan itu sendiri. Ia menjadi badge of honor yang bisa dipamerkan dalam wawancara kerja.

Biaya Tersembunyi dari Kerumitan

Setiap lapisan abstraksi yang kita tambahkan membawa biaya tersembunyi yang besar. Bukan hanya biaya infrastruktur, tetapi biaya kognitif yang jauh lebih mahal. Tim yang harus memahami dua puluh service, lima belas queue, dan tujuh bahasa pemrograman berbeda akan kehilangan kemampuan untuk bergerak cepat. Mereka sibuk memelihara mesin, bukan memecahkan masalah pengguna. Waktu mereka tersedot oleh debugging antar-service, bukan oleh inovasi produk.

Di Wave, mereka dengan sadar memilih Python yang sinkron dan "membosankan". Biaya CPU untuk menunggu I/O memang ada, tetapi biaya tersebut lebih murah dibandingkan biaya tim engineer yang harus memperbaiki bug async yang sulit ditelusuri. Seperti yang ditulis Luu dengan gamblang: "Biaya tim engineering kami sepenuhnya mendominasi biaya sistem yang kami operasikan." Ini adalah perhitungan bisnis yang jarang dilakukan oleh tim yang terlalu cepat mengadopsi teknologi keren hanya karena FOMO.

Kompleksitas sebagai Benteng Ego

Ada dimensi lain yang lebih pribadi di sini. Kompleksitas seringkali berfungsi sebagai benteng ego. Ketika kode kita rumit, kita merasa penting. Kita merasa diperlukan. Siapa lagi yang bisa memahami arsitektur ini selain kita? Ini menciptakan job security yang palsu, tetapi pada saat yang sama menciptakan bus factor yang berbahaya. Tim menjadi sangat bergantung pada satu atau dua orang yang "mengerti sistemnya", dan ketika mereka pergi, sistem tersebut berisiko runtuh seperti rumah kartu.

Software yang sederhana, sebaliknya, adalah software yang tidak membutuhkan pahlawan super. Ia bisa dipelihara oleh engineer junior yang baru masuk. Ia bisa dijelaskan dalam satu halaman diagram. Ia tidak memerlukan dokumentasi sepanjang novel untuk memahami alur data. Ini adalah bentuk kebaikan yang paling mulia dalam software engineering: menulis kode yang tidak memperbudak orang lain.

Kembali pada Pragmatisme

Filsafat worse is better bukan berarti kita harus menulis kode jelek atau mengabaikan kualitas. Ini berarti kita harus memprioritaskan kesederhanaan, keterbacaan, dan kemudahan distribusi dibandingkan kesempurnaan teoritis. Ini berarti kita harus bertanya dengan jujur: apakah fitur ini benar-benar membutuhkan event-driven architecture, atau apakah sebuah cron job sederhana sudah cukup? Apakah kita benar-benar butuh microservices, atau apakah modular monolith bisa mencapai tujuan yang sama dengan sepersepuluh biaya kognitif?

Pragmatisme bukanlah kekurangan imajinasi. Pragmatisme adalah bentuk keberanian untuk mengatakan: "Ini cukup. Kita tidak perlu menambahkan kompleksitas hanya untuk terlihat pintar di depan rekan kerja." Software yang baik bukan software yang paling canggih, melainkan software yang paling mudah dipahami, paling mudah diubah, dan paling tahan lama dalam menghadapi perubahan kebutuhan bisnis.

Refleksi Akhir

Kita hidup di era di mana teknologi baru lahir setiap minggu. AI agent, framework baru, platform baru, paradigma baru. Semuanya menjanjikan produktivitas lebih tinggi dan masa depan yang lebih cerah. Tetapi di tengah kebisingan ini, mungkin kita perlu mengingat kembali sebuah kebenaran lama yang sering terlupakan: kompleksitas adalah musuh yang paling licik. Ia datang dengan kemasan inovasi, padahal ia adalah penyebab utama kegagalan sistem, burnout tim, dan hutang teknis yang membebani generasi engineer berikutnya.

Jadi, pertanyaan yang ingin saya tinggalkan untuk direnungkan: kapan terakhir kali Anda dengan sengaja memilih solusi yang lebih "membosankan" hanya karena itu lebih sederhana? Atau apakah Anda, seperti banyak dari kita, masih terjebak dalam balutan kompleksitas yang Anda bangun sendiri dan sulit untuk dilepaskan?