Lima belas tahun di industri ini, dan proyek yang paling menyakitkan bukanlah yang kodenya berantakan. Justru yang dibangun dengan indah, untuk masalah yang belum tentu ada. Over-engineering adalah pembunuh diam-diam anggaran UKM, dan jarang terlihat seperti kesalahan. Yang terlihat justru seperti engineering yang bagus.
Saya pernah melihat tools internal untuk sepuluh pengguna dibangun di atas enam microservices, message queue, dan cluster Kubernetes. Saya pernah melihat halaman settings tumbuh jadi empat puluh toggle karena "siapa tahu klien mau kustomisasi suatu saat nanti." Tidak ada yang pernah menyentuh toggle-toggle itu. Tapi tagihannya tetap datang tiap bulan.
Polanya selalu sama: seorang engineer merancang untuk skala atau fleksibilitas yang tidak akan pernah dicapai bisnisnya, dan klien akhirnya membayar infrastruktur, bukan hasil.
Kenapa Over-Engineering Terasa Seperti Kemajuan
Kode buruk gampang ketahuan. Dia error, klien komplain, ada yang memperbaiki. Over-engineering tidak mengumumkan dirinya dengan cara yang sama. Dia tetap jalan. Demo-nya lancar. Bahkan berfungsi, di awal. Kerusakannya struktural dan pelan-pelan: setiap perubahan di masa depan sekarang harus melewati lapisan abstraksi yang dibangun untuk masa depan yang tidak pernah datang.
Beberapa alasan jujur kenapa engineer melakukan ini, termasuk saya sendiri di tahun-tahun awal:
- Resume-driven development. Mencoba pattern atau stack baru karena menarik, bukan karena proyeknya butuh.
- Takut salah di kemudian hari. Membangun konfigurasi maksimal supaya tidak ada yang bertanya "kenapa kita tidak rencanakan ini dari awal," padahal sebagian besar rencana itu tidak pernah terpakai.
- Meniru arsitektur perusahaan besar. Perusahaan sepuluh orang tidak butuh topologi service yang sama dengan perusahaan yang memproses jutaan transaksi per hari.
- Menghindari percakapan yang tidak nyaman. Lebih mudah menambah satu lapisan abstraksi lagi daripada bilang ke klien bahwa requirement mereka sebenarnya tidak butuh itu.
Tidak satu pun dari ini karena kebodohan. Ini sering kali orang pintar yang mengoptimalkan hal yang salah. Itulah yang membuat over-engineering begitu mahal: tampilannya seperti kehati-hatian.
Biaya Sesungguhnya
Bagi UKM, kerusakannya bukan sekadar konsep abstrak. Berikut yang saya lihat langsung di lapangan:
| Pilihan over-engineered | Biaya sesungguhnya |
|---|---|
| Microservices untuk produk satu tim | Overhead DevOps 3-5x lipat, onboarding developer baru jadi lebih lambat |
| Business rules engine yang "bisa dikonfigurasi penuh" | Berminggu-minggu waktu build ekstra untuk fleksibilitas yang mungkin dipakai dua kali setahun |
| Framework custom menggantikan tools yang sudah mapan | Setiap karyawan baru butuh berminggu-minggu hanya untuk mempelajari "penemuan" internal Anda |
| Layer caching/queueing yang prematur | Waktu debugging jadi dua kali lipat saat ada masalah jam 2 pagi |
Sebuah jaringan retail di Tangerang pernah meminta saya meninjau sistem sinkronisasi point-of-sale yang terus gagal saat jam sibuk. Vendor sebelumnya membangun arsitektur event-driven dengan lima service bergerak untuk menyinkronkan stok di sebelas toko. Sebelas toko. Satu database dengan indexing yang baik plus scheduled sync job saja sudah cukup menangani beban itu tanpa masalah. Kami membangun ulang dengan lebih sederhana, memangkas biaya infrastruktur bulanan lebih dari separuh, dan sistemnya berhenti gagal.
Kesederhanaan Adalah Disiplin, Bukan Jalan Pintas
Sanggahan yang sering saya dengar adalah solusi sederhana kurang "future-proof." Kenyataannya justru sebaliknya. Sistem yang sederhana lebih mudah diubah di kemudian hari, karena lebih sedikit mesin yang harus diputar-balikkan. Kompleksitas mengunci tebakan pertama Anda tentang masa depan. Kesederhanaan menjaga opsi Anda tetap terbuka.
Aturan praktis saya: bangun untuk beban dan kebutuhan yang benar-benar Anda miliki sekarang, plus buffer yang wajar, bukan beban yang mungkin Anda miliki tiga tahun lagi kalau semuanya berjalan mulus. Kalau berjalan mulus, Anda akan punya revenue untuk mendanai pembangunan ulang. Kalau tidak, Anda tidak membuang enam bulan untuk infrastruktur yang tidak pernah dipakai siapa pun.
Di sinilah technical debt sering disalahpahami. Pemilik bisnis mengira debt hanya muncul dari jalan pintas yang dipotong. Over-engineering juga debt, bedanya cuma denominasinya: kompleksitas yang tidak perlu, bukan test yang hilang.
Tiga Pertanyaan yang Membongkar Over-Engineering di Proposal Vendor
Anda tidak perlu membaca kode untuk menangkap ini. Tanyakan tiga hal ini ke vendor atau tim internal Anda sebelum menyetujui sebuah arsitektur:
- "Apa yang rusak kalau bagian ini tidak dibangun sekarang?" Kalau jawaban jujurnya "tidak ada, minimal untuk setahun ke depan," coret saja.
- "Berapa banyak user atau transaksi kita saat ini yang benar-benar butuh ini?" Lalu tanyakan kenapa arsitektur yang diusulkan disiapkan untuk sepuluh kali lipat angka itu.
- "Kalau tahun depan saya pakai developer lain, berapa lama mereka butuh waktu untuk memahami ini?" Kalau jawabannya menyebut "framework custom" atau "abstraction layer buatan sendiri," itu red flag, bukan nilai jual.
Vendor mana pun yang jadi defensif atas pertanyaan-pertanyaan ini sedang memberi tahu Anda sesuatu. Engineer yang baik bisa membenarkan kompleksitas dalam satu kalimat yang terkait requirement nyata dan terkini. Kalau justifikasinya "best practice" atau "buat jaga-jaga," dorong balik.
Apa yang Harus Dilakukan Sebagai Gantinya
Mulai dengan versi sistem yang membosankan dan jelas. Satu database, satu service yang bisa di-deploy, framework mapan yang sudah dikenal karyawan baru Anda. Tambahkan kompleksitas hanya ketika ada batasan nyata dan terukur yang memaksanya, bukan karena secara teori terlihat elegan. Kalau Anda sedang memetakan ke mana investasi engineering tahun ini, ada baiknya memadukan disiplin ini dengan roadmap AI yang lebih luas, supaya Anda bukan cuma menghindari pemborosan, tapi juga mengarahkan anggaran yang terhemat ke sesuatu yang menghasilkan.
Pujian terbaik yang bisa saya dapat dari klien bukan "ini mengesankan." Tapi "ini jalan terus, dan kami sampai lupa sistemnya ada di sana." Itulah versi pekerjaan saya yang benar-benar pantas dibayar.