Kenapa Developer Senior Mulai Meninggalkan Kompleksitas dan Kembali ke Sistem yang Membosankan?

🌊 Fenomena Nyata di Lapangan

Perhatikan percakapan di komunitas software engineering dalam beberapa tahun terakhir. Di Twitter/X, Hacker News, dan forum Reddit, tren yang muncul adalah para engineer berpengalaman yang mulai bersuara dengan nada yang sama:

• 📌 Dan McKinley (ex-Etsy, Stripe) menerbitkan esai legendaris "Choose Boring Technology" yang hingga kini dijadikan panduan oleh puluhan tim engineering di Fortune 500.
• 📌 DHH (Creator Ruby on Rails, CTO Basecamp) secara terbuka menyatakan Basecamp meninggalkan cloud dan kembali ke server dedicated sendiri—menghemat lebih dari $3 juta per tahun.
• 📌 Pieter Levels (Nomad List, RemoteOK) membangun startup SaaS dengan jutaan pengguna menggunakan PHP + SQLite + satu server tunggal.
• 📌 Amazon Prime Video secara resmi mempublikasikan migrasi mereka dari microservices terdistribusi kembali ke monolith—dan berhasil memangkas biaya 90% sekaligus meningkatkan performa.

Ini bukan kebetulan. Ini adalah pola yang konsisten dari engineer-engineer yang sudah merasakan sendiri pahitnya kompleksitas berlebihan di production environment.

💀 Kutukan Kompleksitas: Ketika "Canggih" Jadi Beban

Coba bayangkan skenario berikut: Sebuah startup dengan 3 developer dan 1.000 pengguna aktif membangun infrastruktur dengan:

• 20+ layanan microservices masing-masing punya repository tersendiri
• Kubernetes cluster dengan 4 node
• Message queue Kafka untuk event streaming
• GraphQL gateway + REST API + gRPC antara service
• Elasticsearch untuk search (padahal query SQL biasa sudah cukup)
• Redis, PostgreSQL, MongoDB (tiga database berbeda untuk satu produk)

Hasilnya? Bukan produk yang lebih baik, melainkan infrastruktur yang jauh lebih sulit dikelola daripada value yang dihasilkan.

"Complexity is the enemy of reliability. Every component you add is another thing that can fail."

— Werner Vogels, CTO Amazon

Biaya Tersembunyi Kompleksitas

Developer junior sering luput memperhitungkan biaya yang tidak terlihat ketika memilih arsitektur yang kompleks:

1. Cognitive Load: Semakin banyak komponen yang harus dipahami developer baru sebelum bisa produktif.
2. Operational Overhead: Monitoring, alerting, on-call rotation yang menjadi lebih kompleks secara eksponensial.
3. Debug Hell: Ketika sistem distributed gagal, mencari sumber masalah di antara puluhan service bisa memakan waktu berjam-jam bahkan berhari-hari.
4. Biaya Cloud yang Meledak: Setiap service butuh instance sendiri, load balancer, storage, bandwidth—biaya membengkak tanpa disadari.
5. Dependency Hell: Ketergantungan library yang saling bertentangan antar service menciptakan masalah yang sulit diprediksi.

🥱 Apa Itu "Boring Technology"?

Istilah "boring technology" dipopulerkan oleh Dan McKinley dari Stripe. Konsep utamanya sederhana namun mendalam:

"Choose technology that has been around long enough that most of its failure modes are well-understood, its quirks are documented, and its community is mature."

Teknologi "membosankan" bukan berarti teknologi yang buruk atau usang. Sebaliknya, ini adalah teknologi yang:

• ✅ Battle-tested — sudah dipakai di production selama bertahun-tahun oleh ribuan perusahaan
• ✅ Well-documented — dokumentasinya lengkap, pertanyaan Stack Overflow-nya bisa dijawab dengan cepat
• ✅ Predictable failure modes — ketika rusak, kamu sudah tahu cara memperbaikinya
• ✅ Large talent pool — mudah merekrut engineer yang paham teknologi ini
• ✅ Stable API — tidak berubah drastis setiap enam bulan sehingga codebase tidak perlu direfactor terus-menerus

Contoh "Boring Stack" yang Powerfull

Inilah yang dimaksud boring stack—terlihat kuno di permukaan, tapi mampu menopang traffic jutaan request per hari:

• 🔷 Linux + Nginx — Web server yang menopang lebih dari 30% seluruh internet dunia
• 🔷 PHP — Menjalankan WordPress (40%+ website global), Facebook (core-nya masih PHP/Hack), Wikipedia
• 🔷 PostgreSQL / MySQL — Relational database yang sudah ada sejak dekade 1970-an dan masih paling reliable hingga sekarang
• 🔷 Redis — Cache sederhana yang sudah terbukti mengurangi database load hingga 80%
• 🔷 Cron Jobs — Background task scheduler yang lebih reliable dari job queue framework "modern" yang sering crash

📖 Kisah Nyata: Dari Kubernetes ke SQLite

Salah satu kisah paling fenomenal di komunitas indie developer adalah perjalanan Pieter Levels. Sebagai pendiri Nomad List—platform yang punya lebih dari 1 juta pengguna terdaftar dan menghasilkan lebih dari $250.000 per bulan—konfigurasi teknisnya mengejutkan banyak developer:

• ✅ Satu server Hetzner seharga €38/bulan
• ✅ PHP + SQLite (ya, bukan MySQL, bukan PostgreSQL—SQLite)
• ✅ Satu file PHP utama berisi ribuan baris
• ✅ Tidak ada framework, tidak ada microservices

"My stack is embarrassingly simple and it handles millions of requests per month. I don't need Kubernetes, I don't need a team of DevOps engineers. I need focus."

— Pieter Levels, @levelsio

Sementara banyak startup dengan valuasi serupa menghabiskan ratusan ribu dolar untuk infrastruktur cloud yang kompleks, Pieter membuktikan bahwa kesederhanaan yang dieksekusi dengan baik mengalahkan kompleksitas yang dieksekusi dengan buruk.

Kasus Amazon Prime Video

Pada Mei 2023, tim Amazon Prime Video mempublikasikan artikel teknis yang menggemparkan dunia software engineering: mereka melakukan migrasi dari arsitektur microservices terdistribusi kembali ke monolith untuk fitur audio/video monitoring mereka. Hasilnya:

• 🚀 Biaya infrastruktur turun 90%
• 🚀 Performa sistem meningkat signifikan
• 🚀 Kompleksitas operasional berkurang drastis

Pesan yang paling keras dari kasus ini: bahkan perusahaan yang pertama kali mempopulerkan microservices pun mengakui bahwa pendekatan itu tidak selalu tepat.

🎯 KISS Principle: Filosofi yang Sering Dilupakan

KISS adalah singkatan dari "Keep It Simple, Stupid"—sebuah prinsip desain yang pertama kali diperkenalkan oleh insinyur angkatan laut Amerika Serikat Kelly Johnson pada tahun 1960. Prinsip ini menyatakan bahwa sebagian besar sistem bekerja terbaik ketika tetap sederhana, dan kompleksitas yang tidak perlu harus dihindari.

Dalam Konteks Software Engineering:

• 📐 Pilih solusi paling sederhana yang menyelesaikan masalah, bukan solusi paling "elegan" atau paling "canggih".
• 📐 Setiap abstraksi baru harus membayar biayanya sendiri dalam bentuk kemudahan pemeliharaan yang sepadan.
• 📐 "Premature optimization is the root of all evil" (Donald Knuth). Jangan optimalkan apa yang belum terbukti menjadi bottleneck.
• 📐 Kode yang bisa dibaca oleh junior developer lebih berharga daripada kode yang hanya bisa dipahami oleh arsitek senior.

Tanda-tanda Over-Engineering yang Harus Diwaspadai

Bagaimana mengenali apakah sebuah sistem sudah over-engineered? Perhatikan sinyal berikut:

1. Dokumentasi arsitektur lebih tebal dari dokumentasi fitur produk
2. Waktu rata-rata onboarding developer baru > 2 minggu hanya untuk memahami infrastruktur
3. Tim lebih sering membicarakan infrastructure daripada membicarakan kebutuhan pengguna
4. Deployment membutuhkan lebih dari 30 langkah manual
5. Tidak ada yang berani refactor kode lama karena takut memecah service lain
6. Anda menggunakan machine learning untuk menyelesaikan masalah yang bisa diselesaikan dengan if-else

⚖️ Kapan Kompleksitas Memang Dibutuhkan?

Penting untuk digarisbawahi: artikel ini bukan anti-kompleksitas secara mutlak. Ada kasus nyata di mana arsitektur yang kompleks memang dibutuhkan dan justified:

✅ Kompleksitas yang Justified:

• Traffic yang benar-benar massive: Netflix, Tokopedia, Gojek memproses jutaan request per detik. Skalabilitas horizontal melalui microservices memang dibutuhkan.
• Regulatory compliance: Sistem perbankan, kesehatan, dan pemerintahan sering membutuhkan isolasi antar komponen karena alasan keamanan dan kepatuhan regulasi.
• Tim yang besar dan terdistribusi: Jika 200 developer perlu bekerja pada codebase yang sama tanpa saling mengganggu, arsitektur terdistribusi memang masuk akal.
• Domain yang secara inheren kompleks: Real-time financial trading systems, autonomous vehicle software, dan air traffic control memiliki kompleksitas domain yang harus tercermin dalam arsitekturnya.

❌ Kompleksitas yang Tidak Justified:

• Startup tahap awal dengan < 10.000 pengguna yang membangun infrastruktur "siap untuk satu miliar pengguna"
• Menggunakan message queue untuk operasi yang cukup diselesaikan dengan database transaction
• Membangun custom framework karena "lebih fleksibel" padahal belum tahu masalah spesifik yang akan dihadapi
• Memilih NoSQL hanya karena terdengar modern, padahal data memiliki relasi yang jelas dan terstruktur

🔧 Stack "Membosankan" yang Justru Teruji

Berikut beberapa kombinasi stack yang mungkin terdengar membosankan di telinga developer yang gemar mengikuti tren, namun terbukti reliable di production nyata:

1. LAMP / LEMP Stack (Classic)

Linux + Apache/Nginx + MySQL + PHP — Kombinasi yang menjalankan lebih dari separuh internet. WordPress (40%+ seluruh website di dunia), Drupal, Joomla, dan ribuan aplikasi enterprise dibangun di atas stack ini.

2. Rails Monolith

Ruby on Rails + PostgreSQL + Heroku — Shopify dibangun dengan Rails. GitHub menggunakan Rails hingga skalanya sangat besar. Basecamp masih menggunakan Rails. Sebuah monolith Rails yang dioptimalkan dengan baik bisa menangani ratusan ribu pengguna aktif tanpa masalah.

3. Django + PostgreSQL

Python + Django + PostgreSQL — Instagram dibangun dengan Django sebelum akhirnya melakukan migrasi. Disqus, Pinterest awal, dan banyak startup unicorn memulai perjalanan mereka dengan stack ini.

4. The PHP + MySQL Combo

Meskipun sering diremehkan, PHP 8.x + MySQL + ORM sederhana tetap menjadi pilihan yang masuk akal untuk banyak use case. Performa PHP modern (terutama dengan OPcache) sudah jauh melampaui reputasi buruknya di masa lalu.

"PHP is the most popular server-side language, not despite its warts, but because of its pragmatism. It's boring in the best possible way."

Rekomendasi Stack Per Skenario

🎓 Pelajaran untuk Developer Junior

Jika Anda seorang developer junior atau mid-level yang sedang membangun karir, ada beberapa insight penting dari tren ini yang perlu dicatat:

1. Pahami "Mengapa" Sebelum Memilih "Apa"

Sebelum memilih teknologi, tanyakan dulu: Masalah apa yang sebenarnya perlu diselesaikan? Microservices, Kubernetes, GraphQL—semuanya adalah solusi untuk masalah spesifik pada skala tertentu. Menggunakannya sebelum Anda memiliki masalah tersebut adalah seperti membeli ambulans karena suatu hari nanti mungkin Anda sakit.

2. Kuasai Fondasi, Bukan Trend

Developer yang paling dicari bukan yang paling tahu framework terbaru, tapi yang paling paham fundamental:

• SQL dan cara kerja relational database (indexing, query optimization, normalization)
• HTTP protocol, DNS, TCP/IP — bagaimana internet sebenarnya bekerja
• Data structures & algorithms — bukan untuk interview, tapi untuk memahami trade-off
• Linux command line dan sistem administrasi dasar
• Security fundamental: OWASP Top 10, SQL injection, XSS, CSRF

3. Senioritas Bukan Tentang Teknologi Terbaru

Developer senior yang sesungguhnya dikenal dari kemampuannya untuk:

• Mempertanyakan requirement sebelum mulai coding
• Memilih solusi paling sederhana yang menyelesaikan masalah
• Mendokumentasikan keputusan teknis beserta alasannya (Architecture Decision Records)
• Memprediksi titik kegagalan sebuah sistem sebelum dibangun
• Mengatakan "tidak" pada fitur yang tidak perlu

"The best code is no code at all. Every line you write is a liability. Every system you build is one more thing that can fail."

— Jeff Atwood, Co-founder Stack Overflow

4. Production Experience > Tutorial Experience

Tidak ada yang mengajarkan pentingnya kesederhanaan lebih baik daripada pengalaman langsung mengelola sistem yang kompleks di production—jam 3 pagi—ketika ada insiden kritis dan Anda harus debug di antara 20 microservices yang saling berinteraksi. Pengalaman inilah yang mengubah perspektif banyak developer senior.

🏁 Kesimpulan: Membosankan adalah Strategi

Tren developer senior yang kembali ke sistem sederhana dan "membosankan" bukan tentang nostalgia atau kemunduran. Ini tentang kematangan engineering judgment.

Mereka telah belajar—kadang dengan cara yang menyakitkan—bahwa kompleksitas yang tidak perlu adalah musuh tersembunyi dari reliability, maintainability, dan kecepatan pengembangan. Mereka telah melihat sendiri bagaimana sistem yang "keren" di whiteboard bisa menjadi mimpi buruk di production.

Mengutip kembali prinsip McKinley: pilih teknologi yang membosankan agar Anda bisa berinovasi di tempat yang benar-benar penting. Simpan "token inovasi" Anda untuk produk dan fitur, bukan untuk infrastruktur yang tidak ada yang peduli.

Pada akhirnya, engineer terbaik bukan yang membangun sistem paling kompleks. Engineer terbaik adalah yang membangun sistem paling sederhana yang tetap bisa menyelesaikan pekerjaan dengan baik—dan bertahan di production tanpa pageant jam 3 pagi.