Lotus Notes dan Bahaya Rewrite dari Nol: Kenapa Sering Gagal?

Kamu pasti pernah dengar nasihat klasik: "Jangan rewrite dari nol, nanti kacau." Tapi jujur, berapa kali kamu tetap ngincar bersih-bersih kode lama soalnya terasa "terlalu kotor" atau "udah tidak relevan"? Cerita Lotus Notes di era 90-an sampai 2000-an adalah bukti nyata kenapa insting itu sering menipu. Saat itu, Notes udah jadi platform kolaborasi enterprise paling dominan — email, database, workflow, semuanya dalam satu paket. Tapi di balik keberhasilan itu, tim engineering mereka terjebak dalam siklus rewrite yang hampir membunuh produk mereka.

Masalahnya dimulai saat arsitektur asli Notes — yang dibangun di atas konsep document-oriented database dan replication peer-to-peer — mulai terasa ketinggalan jaman. Web browser jadi standar, user mau UI yang lebih ringan, dan kompetitor seperti Microsoft Exchange mulai ngejar pangsa pasar. Manajemen lalu ambil keputusan besar: bangun versi baru total dari nol, buang semua legacy code, dan targetkan rilis dalam 18 bulan. Realita? Proyek itu berlarut-larut sampai 5 tahun, budget meledak, dan versi baru yang akhirnya keluar (Notes 6/7) masih penuh bug dan kehilangan fitur-fitur kritis yang versi lama punya secara native.

Kenapa rewrite dari nol hampir selalu gagal

Pola ini gak cuma terjadi di Lotus Notes. Netscape Navigator, Windows Vista, dan ratusan startup modern pun mengalami nasib mirip. Alasannya sederhana tapi sering diabaikan: kode lama itu bukan cuma "kotoran" — dia adalah rekam jejak ribuan keputusan bisnis, edge case handling, dan bug fix yang udah teruji produksi. Kalau kamu buang semuanya sekaligus, kamu juga buang pengetahuan domain yang nggak tertulis di dokumen manapun. Tim baru harus rediscover semua edge case itu satu per satu, sambil user menunggu fitur yang mereka butuhkan hari ini. Di era AI sekarang, tekanan untuk "rewrite pakai LLM" makin besar — tapi prinsipnya sama: konteks bisnis itu mahal, dan nggak bisa digenerate oleh model apapun.

Lotus Notes akhirnya survive karena mereka mundur strategi: bukan rewrite total, tapi refactor bertahap. Mereka pecah monolith jadi komponen-komponen yang bisa di-upgrade independen, biarkan core replication engine yang udah matang jalan seperti biasa, dan hanya ganti layer UI dan integrasi web. Pendekatan ini butuh waktu lebih lama di awal, tapi risikonya jauh lebih kecil. Buat kamu yang lagi ngurus codebase legacy — apakah itu monolith PHP 10 tahun lalu, atau pipeline ML yang penuh duct tape — pelajarannya sama: identifikasi bagian yang benar-benar blokir bisnis, fix itu dulu, dan biarkan yang lain jalan selama masih aman.

Strategi aman: strangler fig pattern dan feature flags

Pola yang sekarang jadi standar industri adalah Strangler Fig: kamu bungkus sistem lama dengan facade, lalu routing traffic ke komponen baru sedikit demi sedikit. Kombinasiin dengan feature flags, kamu bisa deploy kode baru ke production tanpa user sadar, test di subset user, dan rollback instan kalau ada masalah. Lotus Notes jaman dulu nggak punya tooling kayak ini — deploy berarti shutdown server, copy file, doa. Sekarang kamu punya Kubernetes, canary deployment, observability stack lengkap. Nggak ada alasan buat "big bang rewrite" lagi, kecuali sistem lama benar-benar tidak bisa di-extend lagi (misal: bahasa pemrograman udah tidak didukung, hardware obsolete, atau lisensi legal bermasalah).

Takeaway praktis buat hari ini: sebelum ngajukan proposal rewrite ke manajemen, bikin daftar risiko spesifik — bukan "kode jelek" tapi "fitur X nggak bisa ditambah karena coupling di module Y, estimasi 3 sprint buat decouple." Hitung cost of delay: berapa revenue hilang kalau fitur baru tertunda 6 bulan menunggu rewrite? Bandingin dengan cost refactor bertahap 2 sprint per quarter. Sering kali angkanya mengejutkan: refactor bertahap lebih cepat nge-deliver value ke user. Dan ingat, user nggak peduli arsitektur kamu — mereka peduli fitur jalan, cepat, dan nggak crash.

Kode legacy itu bukan utang teknis — itu adalah aset yang sudah terbukti menghasilkan uang. Rewrite total itu seperti membakar rumah buat bangun yang baru, sambil keluarga kamu masih tinggal di dalamnya.

• Audit dulu: mana bagian yang benar-benar blokir bisnis vs cuma "terasa kotor"
• Targetkan quick win: refactor satu module kritis, deploy, ukur impact
• Gunakan feature flags untuk migrasi bertahap tanpa downtime
• Jaga test coverage tinggi SEBELUM mulai ubah kode lama
• Komunikasikan ke stakeholder dalam bahasa bisnis, bukan teknis