Seni Mengurangi: Filosofi Subtraction dalam Membangun Software

Pernahkah kamu membuka kembali codebase yang kamu bangun enam bulan lalu dan bertanya-tanya: kenapa fitur ini ada? Kenapa arsitekturnya serumit ini? Kenapa tidak ada yang berani menghapus baris kode mati yang sudah mengendap sejak sprint pertama?

Kita hidup di era yang menyembah penambahan. Setiap sprint review dipenuhi dengan demo fitur baru. Setiap pull request yang besar dianggap produktif. Setiap rilis versi mayor membawa daftar changelog yang panjang. Tapi kita jarang bertanya: apakah software kita semakin baik karena semakin banyak, atau justru semakin berat karena semakin penuh?

Paradoks ini bukan hanya masalah teknis. Ia adalah masalah filosofis yang menyangkut bagaimana kita mendefinisikan kemajuan dalam pekerjaan kita sehari-hari.

Obsesi Terhadap Penambahan

Dalam penelitian antropologis terhadap perilaku engineer, pola yang muncul secara konsisten adalah kecenderungan untuk menyelesaikan masalah dengan menambahkan sesuatu. Butuh logging? Tambahkan library. Butuh cache? Tambahkan Redis. Butuh validasi? Tambahkan schema. Tiap lapisan terdengar rasional secara individual, tapi secara kolektif mereka membentuk monster yang sulit dipahami, apalagi dihapus.

Tim product sering merasa bangga dengan velocity tinggi. Tapi velocity diukur dari jumlah story point yang diselesaikan, bukan dari jumlah kompleksitas yang dihilangkan. Tidak ada metrik untuk "berapa banyak kode yang kita hapus minggu ini." Tidak ada sprint goal yang berbunyi: minggu ini kita menyederhanakan tiga modul legacy dan mematikan satu microservice yang tidak terpakai.

Bahkan dalam hiring, kita sering mencari engineer yang "bisa membangun sistem skala besar." Jarang ada lowongan yang mencari engineer yang "bisa merampingkan sistem skala besar menjadi sistem yang lebih kecil tanpa kehilangan fungsionalitas." Padahal kedua skill itu sama-sama langka dan bernilai tinggi.

Filosofi Subtraction yang Terlupakan

Antoine de Saint-Exupéry pernah menulis: "Kesempurnaan tercapai bukan ketika tidak ada yang bisa ditambahkan, tapi ketika tidak ada yang bisa dikurangkan." Kutipan ini sering dipajang di dinding startup, tapi jarang dijalankan di dalam IDE.

Apple di bawah Steve Jobs adalah contoh ekstrem dari filosofi subtraction. iPhone pertama diluncurkan tanpa keyboard fisik, tanpa slot memori eksternal, tanpa Flash. Keputusan-keputusan itu dianggap kontroversial, tapi justru karena apa yang dihilangkanlah produk itu menjadi revolusioner. Software engineer bisa belajar banyak dari pendekatan ini: kemampuan untuk mengatakan "tidak" terhadap fitur sering kali lebih berharga daripada kemampuan untuk mengimplementasikannya.

Dunia software open source pun punya cerita serupa. Suckless.org, komunitas yang membangun tools seperti dwm dan st, menganut filosofi bahwa software yang baik adalah software yang memiliki codebase kecil, sederhana, dan transparan. Mereka tidak berusaha memenuhi setiap use case. Sebaliknya, mereka memangkas hingga hanya sisa esensi yang paling murni. Hasilnya? Tools yang sudah bertahan puluhan tahun dengan codebase yang bisa dipahami dalam satu malam.

YAGNI dan Biaya Tersembunyi

Prinsip YAGNI (You Arent Gonna Need It) sudah ada sejak era Extreme Programming, tapi masih diabaikan. Developer senior sekalipun sering terjebak membangun abstraction layer untuk kasus edge yang mungkin terjadi dua tahun lagi. Abstraction itu terlihat elegan di diagram, tapi di dunia nyata ia menambah beban kognitif, memperlambat onboarding, dan meningkatkan surface area untuk bug.

Kompleksitas tidak hanya datang dari fitur yang aktif. Ia datang dari fitur yang hampir aktif, dari flag yang hampir ter-trigger, dari modul yang hampir terpakai. Setiap baris kode yang ada di repository adalah baris kode yang harus di-build, di-test, di-deploy, di-monitor, dan di-debug. Kode adalah liabilitas, bukan aset. Semakin sedikit kode yang kamu miliki untuk mencapai tujuan yang sama, semakin kaya kamu secara teknis.

Sebuah studi dari NIST memperkirakan biaya perbaikan bug meningkat secara eksponensial seiring fase development. Kompleksitas berlebih adalah bibit bug. Menambahkan kode yang tidak perlu bukan hanya memboroskan waktu penulisan, tapi juga memboroskan waktu debugging di masa depan.

Ketakutan akan Penghapusan

Mengapa kita sulit menghapus? Karena menghapus terasa seperti kehilangan. Menghapus berarti mengakui bahwa keputusan masa lalu mungkin salah. Menghapus berarti konfrontasi dengan sunk cost fallacy. Menghapus juga berarti risiko: bagaimana jika ada user yang masih memakainya? Bagaimana jika stakeholder protes?

Tapi pengalaman menunjukkan bahwa penghapusan yang terencana jarang menimbulkan kerusakan besar. Netflix rutin mematikan fitur dan eksperimen yang tidak memenuhi ekspektasi. Amazon punya kultur untuk mengakhiri proyek yang tidak berkembang. Mereka memahami bahwa ruang kosong yang diciptakan oleh penghapusan justru memberi tempat bagi inovasi baru untuk tumbuh. Seperti pohon yang dipangkas agar cabang-cabang baru bisa keluar, codebase yang diperamping akan lebih sehat.

Praktik Subtraction di Tim Engineering

Menerapkan filosofi subtraction tidak berarti secara acak menghapus kode setiap Jumat. Ia membutuhkan disiplin. Berikut beberapa praktik yang bisa mulai diterapkan:

• Audit fitur aktif secara berkala. Gunakan analytics dan telemetry untuk melihat fitur mana yang benar-benar dipakai oleh mayoritas user. Fitur dengan adoption di bawah lima persen harus menjadi kandidat deprecation.

• Adopsi "reverse RFC." Alih-alih menulis proposal untuk fitur baru, tulis proposal untuk fitur yang akan dihapus. Jelaskan risiko, timeline, dan strategi migrasi. Proses ini memaksa tim untuk mempertimbangkan cost of keeping secara eksplisit.

• Ukur complexity budget. Setiap tim seharusnya punya batasan kompleksitas yang tidak bisa dilanggar. Mau menambahkan library baru? Hapus dua yang sudah ada. Mau membuat microservice baru? Gabungkan tiga yang terlalu kecil.

• Rayakan deletion. Jadikan penghapusan kode sebagai prestasi. Beberapa tim di Google dan Shopify memang memiliki tradisi merayakan commit dengan jumlah baris kode bersih negatif terbesar.

Refleksi Akhir

Software engineering sering disalahpahami sebagai profesi yang membangun. Padahal setengah dari pekerjaan yang berkualitas adalah pekerjaan yang menghancurkan: menghapus, menyederhanakan, dan meluruskan. Seperti seorang penulis yang menulis draft panjang lalu memangkas hingga hanya tersisa kalimat-kalimat yang bernyawa, developer yang hebat adalah developer yang berani menghapus.

Di dunia yang terus memaksa kita untuk menambah, memilih untuk mengurangi adalah tindakan pemberontakan. Tapi justru di dalam ruang kosong itulah kita menemukan kejelasan.

Jadi, apa yang bisa kamu hapus dari codebase-mu minggu ini?