Fast - Kekuatan Perangkat Lunak yang Cepat

• Dalam pengembangan perangkat lunak, jarang ada yang secara langsung menuntut kecepatan (fast), tetapi perangkat lunak yang cepat mengubah perilaku pengguna
• Teknologi seperti deployment cepat dan streaming real-time secara revolusioner meningkatkan efisiensi kerja dan kerja jarak jauh
• Perangkat lunak yang lambat menimbulkan friksi kognitif dan benar-benar menjadi faktor yang sangat menurunkan produktivitas pengguna
• Perangkat lunak yang cepat tidak menyembunyikan kompleksitas, melainkan menunjukkan kesederhanaan dan fokus
• Ke depan, di industri pengembangan akan makin kuat arus yang menekankan optimasi performa dan pengalaman

---

Industri perangkat lunak yang tidak menuntut kecepatan

• Di industri perangkat lunak, yang biasanya diminta adalah fitur, harga, integrasi data, dan sebagainya, tetapi jarang ada yang secara langsung meminta ‘cepat’
• Namun, perangkat lunak yang cepat memiliki kekuatan untuk mengubah perilaku pengguna itu sendiri
• Jika waktu untuk men-deploy kode berkurang hingga hitungan detik, frekuensi deployment para developer juga meningkat
• Fitur autocomplete kode berbasis kecerdasan buatan memudahkan pembuatan prototipe dalam bahasa yang belum familier
• Teknologi streaming real-time membuka kemungkinan kerja jarak jauh

Batasan perangkat lunak yang lambat

• Perangkat lunak yang lambat memberi lebih banyak batasan daripada yang kita kira
• Sebagai contoh, saat menggunakan WiFi pesawat, kita bisa mengalami situasi di mana sulit menghasilkan pekerjaan yang berarti
  • Paling-paling hanya bisa mengirim pesan Slack atau membalas email,
  • Google Docs sering kali tidak berfungsi dengan baik
  • Pada akhirnya, pengalaman pengguna berujung pada menyerah
• Sebaliknya, layanan seperti Instagram secara konsisten memberikan pengalaman yang cepat

Dampak perangkat lunak yang cepat

• Kecepatan terasa seperti sihir
• Perangkat lunak yang cepat menghilangkan friksi kognitif dan, seperti Raycast atau Superhuman, merespons selangkah lebih cepat dari perkiraan
• Waktu respons di bawah 100 ms milik Superhuman dan dukungan shortcut yang luar biasa merevolusi pengalaman menggunakan email
• Fitur transfer instan milik Mercury juga memberi kejutan bagi pengguna yang sudah terbiasa dengan transaksi perbankan yang lambat
• Kecepatan alat-alat ini mungkin tidak dipuji secara eksplisit, tetapi itulah faktor yang membuat pengguna merasakannya seperti sihir

Kecepatan, kesederhanaan, dan fokus

• Cepat berarti sederhana, dan ini adalah nilai yang makin langka di lingkungan perangkat lunak modern
• Agar perangkat lunak bisa cepat, dibutuhkan upaya untuk menghapus fitur yang tidak perlu
• Alat manajemen proyek yang ringkas seperti Linear memberikan pengalaman penggunaan yang jauh lebih cepat dibanding aplikasi enterprise seperti Workday atau Oracle
• Kecepatan adalah bentuk penghormatan kepada pengguna, yang menunjukkan bahwa elemen-elemen yang tidak perlu telah benar-benar disaring

Upaya tersembunyi untuk membuatnya cepat

• Untuk membuat perangkat lunak yang cepat, dibutuhkan optimasi backend yang kompleks
• Di Cash App, ada upaya untuk hanya menambahkan langkah-langkah yang benar-benar penting dalam perjalanan pengguna, sementara kompleksitas ditangani di balik layar
• Saat mengunggah foto, Instagram memulai upload bersamaan dengan pengguna mengetik caption, sehingga pengguna merasa unggahan dimulai seketika
• Kecepatan bukan sekadar pencapaian teknis, melainkan hasil dari prioritas dan fokus

Kecepatan sebagai kesenangan dan motivasi

• Perangkat lunak yang cepat dengan sendirinya memberi kesenangan dan kepuasan
• Bahkan dalam hal-hal kecil seperti pengukuran kecepatan mengetik (WPM) atau pengaturan shortcut, pengguna menikmati pengalaman menjadi lebih cepat

Relativitas kecepatan

• Workflow berbasis AI dan LLM memberikan pengalaman yang jauh lebih cepat dibanding cara tradisional
• Misalnya, meminta LLM melakukan riset dalam 6 menit dapat menghasilkan produktivitas lebih dari 10.000 kali lebih cepat dibanding sebelumnya
• Namun, dalam proses pengembangan, build, dan deployment aplikasi AI saat ini, masih ada banyak kekurangan dibanding era perangkat lunak sebelumnya
• Pada titik ini, fokus masih lebih besar pada fitur baru daripada performa dan pengalaman
• Di masa depan, akan datang arus yang memprioritaskan optimasi seperti latensi rendah, desain antarmuka, konektivitas, dan keandalan
• Ketika itu terjadi, akan terbuka lebih banyak kemungkinan baru dan evolusi pengalaman pengguna

Referensi

• Berikut beberapa bacaan tambahan yang berguna tentang kecepatan
  • Patrick Collison: https://patrickcollison.com/fast
  • Charlie Marsh: https://notes.crmarsh.com/python-tooling-could-be-much-much-faster
  • Paul Graham: https://www.paulgraham.com/growth.html

[GN⁺]

Komentar Hacker News

• Saya sangat berterima kasih karena YCom menjaga antarmuka HN tetap cepat dan baik. Saya pernah langsung meninggalkan Slashdot setelah mereka mengganti total antarmukanya dengan dalih "UI modern", lalu berubah jadi penuh ruang kosong dan susah dipindai. Dulu itu situs yang saya baca setiap hari
  • Kepadatan informasi dan kemampuan menemukan informasi yang diinginkan dengan cepat adalah konsep yang sepenuhnya berlawanan dengan "engagement". Sering kali situs sengaja dibuat rumit untuk menaikkan angka waktu tinggal agar terlihat menarik bagi pengiklan. Halaman dimuat dengan lambat secara sengaja supaya orang salah klik dan mendorong "konversi". Kenyataannya, menghasilkan uang sering kali lebih mudah dengan menipu orang daripada benar-benar berfokus pada pengguna
  • HN adalah situs yang saya buka untuk mengecek apakah koneksi internet saya hidup. Di tengah segala web bloat, ini benar-benar menonjol
  • UI HN juga perlu ditingkatkan, terutama di mobile. Kontrasnya rendah, tombolnya terlalu kecil sehingga sulit dipakai, tidak ada dark mode, dan ada beberapa kekurangan lain. Saya punya versi UI ideal menurut saya yang dibuat dengan Elm, sepenuhnya client-side, memakai HN firebase API: https://seville.protostome.com/
  • Saya tidak berpikir Slashdot runtuh karena UI. Nilai sebenarnya ada pada komentar dari para SME berkualitas tinggi di masa-masa awal. Setelah situs itu dijual, sepertinya penurunannya dimulai karena pengguna yang mutunya lebih rendah, moderasi yang buruk, dan eksodus pengguna. Ajaib juga situs itu masih hidup
  • orange site (HN) masih belum mendukung tag tautan Markdown
• Saya merasa workflow yang mengadopsi LLM dalam praktiknya sering kali justru lebih lambat. Fitur "refactor" di IDE selesai dalam 1 detik, tetapi jika diserahkan ke asisten AI bisa makan 30 detik, dan pendekatan "agent" bisa butuh 15 menit. Misalnya, saya pernah menyuruh agent menangani kode endpoint HTTP dan awalnya merasa "pekerjaan sehari selesai dalam 10 menit", tetapi saat dicek lagi ternyata logikanya kusut dan penanganan error-nya juga buruk. Akhirnya saya menulis ulang sendiri sekitar 5 jam, dan hasilnya selesai dengan pengujian yang lebih baik dari standar saya sebelumnya serta error handling yang bahkan lebih baik daripada jika saya kerjakan sendiri. Ada juga riset terkait https://www.reddit.com/r/programming/comments/1lxh8ip/study_finds_that_ai_tools_make_experienced/
  • Saya sudah beberapa kali menulis soal topik ini. Menurut saya, LLM yang mengejar skor benchmark adalah arah yang keliru jika dilihat sebagai alat pemrograman. Dalam pengalaman saya, kemungkinan salahnya cukup tinggi sehingga hasilnya selalu harus diperiksa, membuat waktu bolak-balik dengan LLM makin panjang, dan karena jawabannya lambat, saya sering merasa lebih cepat kalau bikin sendiri dengan tangan. Yang saya inginkan justru agent dengan kemampuan setara benchmark 60% tetapi merespons langsung dalam kurang dari 1 detik
  • Satu-satunya hal yang benar-benar mempercepat pekerjaan saya dari LLM adalah sebagai semacam find/replace tingkat lanjut untuk kode. Misalnya prompt seperti minta mengganti "logika terkait XXX" di berbagai tempat dalam kode dengan sesuatu yang lain, itu dijawab cukup baik. Sangat mengurangi repotnya mencari lalu mengubah satu per satu. Tapi saya belum pernah mencobanya pada basis kode yang sangat besar
  • Sepertinya tergantung situasi. Untuk refactor, kalau IDE atau language server mendukung, itu jauh lebih cepat; selain itu LLM juga bisa membantu. Contohnya kemarin saya membuat logika normalisasi URL sebagai MVP, dan di data pelanggan ada banyak variasi URL sehingga ada banyak kasus validasi. Saya memasukkan contoh pelanggan yang paling sering dipakai ke Claude dan meminta dibuatkan "minimal spanning test cases", lalu dalam 5–10 detik hasilnya keluar. Berdasarkan itu, saya memakai fitur agent Opus di Zed untuk membuat file test, lalu meninjau kasus-kasusnya, merapikan bagian yang tidak perlu, dan sedikit memperbaiki logikanya. Cara ini jauh lebih cepat daripada membuat semuanya sendirian
  • Saya sering mendengar, baik online maupun offline, bahwa untuk pekerjaan senior kecepatannya bisa naik 40–60%. Meski begitu, rasanya belum sampai tahap bisa santai total dan menyerahkan semuanya hanya pada agent AI
• Ini cerita saat saya masih junior dan mendapat reputasi sebagai software engineer yang bisa meningkatkan kecepatan. Waktu itu masih era ketika pengetahuan algoritme dan kemampuan membaca output compiler sama-sama penting, dan masa ketika Carmak serta Abrash sedang menjadi bintang. Di usia 22 tahun saya pertama kali ikut rapat dengan klien perusahaan multinasional besar, dan mereka menyoroti masalah kecepatan produk kami. Saya benar-benar terkejut saat mendengar VP perusahaan itu berkata langsung, "1 detik lebih cepat berarti tambahan 1 juta dolar laba tahunan bagi kami." Itu adalah momen penentu pertama kali saya melihat kecepatan diterjemahkan langsung menjadi uang. Bahkan 20 tahun kemudian, itu tetap jadi salah satu sorotan terbesar dalam karier saya. Lalu ada engineer lain yang bercanda kepada VP itu, "Kalau begitu, kalau kita turunkan sampai 0 detik, apakah kita bisa dapat uang tak terbatas?" Di ruangan itu tak ada yang tertawa, tapi menurut saya itu cukup lucu
  • Dari 1 detik ke 0 detik, atau dari 2 detik ke 1 detik, bukankah masing-masing berarti tambahan 1 juta dolar? Mengapa logikanya harus menjadi uang tak terbatas terasa aneh
  • Jadi penasaran apakah akhirnya benar-benar jadi lebih cepat
• Saya menulis tanggapan ini karena setuju dengan kalimat pertama di tulisan blog itu. Pengguna memang tidak secara langsung meminta developer untuk "membuatnya cepat", tetapi kalau tidak cepat mereka juga tidak akan percaya. Jika Rust lebih lambat daripada Ruby, tidak akan ada yang tertarik. Rust baru mendapat perhatian ketika disebut "lebih cepat dari C++". Di HN pun, asal ada unsur "cepat", semua orang seperti langsung antusias. Begitu sedikit saja lebih cepat, langsung menarik perhatian
  • Itu cuma berlaku untuk lapisan kecil programmer yang menulis di HN. Kebanyakan developer dan pengguna umum tidak terlalu peduli kalau sesuatu lambat, selama UI-nya nyaman. Bahkan data scientist profesional pun sering memakai Github Desktop yang rapi ketimbang command yang supercepat
  • Kesimpulannya terasa salah. "Cepat" itu pembeda yang kuat ketika memberikan himpunan fitur yang sama dengan lebih cepat. Orang akan datang ke "X yang lebih cepat dari X", tetapi mereka juga bisa pindah karena fitur lebih banyak, UX lebih baik, harga lebih murah, atau kualitas lebih baik, dan tetap bisa memilih sesuatu yang lebih lambat
  • Dalam bahasa pemrograman atau runtime, kecepatan itu penting, tetapi saat memakai framework, faktor lain seperti fitur dan kompatibilitas lebih penting. Orang tetap banyak memakai Electron meskipun lambat
  • Kita benar-benar hidup di dunia di mana banyak aplikasi, terutama web, sangat lambat. Sangat sering saat pengguna melakukan sesuatu, perlu beberapa detik sebelum ada respons. Jadi meskipun orang berkata "yang cepat itu terbaik", kenyataannya justru sebaliknya
  • Alasan pengguna HN menyukai 'cepat' adalah karena kami tahu bahwa sebagian besar teknologi yang kami pakai saat ini terlalu lambat, dan secara mendasar sebenarnya bisa dibuat jauh lebih cepat
• Sebaliknya, kalau sesuatu "terlalu" cepat, orang juga bisa curiga apakah benar-benar bekerja. Dalam kasus TurboTax, analisis sebenarnya selesai bahkan kurang dari 1 detik, tetapi ketika mereka sengaja menambahkan layar loading palsu, orang justru lebih percaya dan lebih menyukainya. Jadi meskipun pemrosesan sesungguhnya jauh lebih singkat, mereka sengaja membuatnya terlihat lambat demi membangun keyakinan bahwa sistem itu benar-benar sudah memeriksa
• Cepat juga penting dari sisi biaya. Dalam cloud, saat biaya dihitung per detik, mustahil menyediakan layanan transkripsi yang murah untuk seluruh perusahaan jika setiap proses tidak dioptimalkan. Misalnya, image yang saya buat menjadi 2,5 kali lebih kecil dibanding alternatif open source, dan itu menghasilkan cold boot yang lebih cepat, biaya lebih rendah, dan layanan yang lebih baik https://speechischeap.com
  • Apakah S3 lambat atau cepat? Kenyataannya dua-duanya. Kalau dilihat dari satu request tunggal, ia lambat, tetapi kalau menembakkan banyak request secara paralel, ia terasa cepat. Pada akhirnya, 'cepat' kadang penting untuk bertahan hidup, dan kadang juga merupakan suatu estetika
  • Saya justru sebaliknya: saya menjalankan layanan di hardware konsumen sehingga operasionalnya jauh lebih murah daripada cloud. Tidak perlu khawatir soal ukuran image (bare metal lebih cepat). Saya bahkan menyediakan transkripsi gratis sampai 20 ribu menit per bulan (dengan batas 5 detik per permintaan). Saya juga sedang mengembangkan alternatif open source dan lintas platform terkait https://geppetto.app https://github.com/Mozilla-Ocho/llamafile/tree/main/whisper.cpp https://github.com/cjpais/whisperfile https://handy.computer Jika tertarik pada inovasi layanan transkripsi, silakan hubungi saya
  • Saya berharap alat seperti PAPER bisa dibuat dengan ukuran instalasi total di bawah 2MB, setidaknya di Linux, termasuk cache. pip berukuran 10–15MB, pipx lebih besar lagi, dan uv 35MB. Saya sedang berusaha membuatnya lebih kecil dari itu
  • Cepat tidak selalu berarti ringan dan efisien. Sering kali sesuatu dibuat cepat dengan menggelontorkan banyak hardware mahal
• Setiap kali saya melihat artikel yang mengeluhkan transfer bank di Amerika, saya selalu mengingatkan diri sendiri bahwa di Inggris atau Swiss transfer bank nyaris instan. Saya penasaran kenapa Amerika begitu lambat
  • Bank-bank regional di AS hampir tidak punya programmer internal dan bergantung pada "core processor". Karena itu upgrade sistem berjalan sangat lambat. Penerapan Faster ACH pun memakan waktu bertahun-tahun, dan lobi bank regional berargumen bahwa penerapannya perlu ditunda karena merugikan mereka. Ada blog yang menjelaskan ini dengan sangat baik https://www.bitsaboutmoney.com/archive/community-banking-and-fintech/
  • ACH lambat karena penjadwalan dan pemrosesan batch. Transfernya sendiri bisa selesai segera, tetapi biasanya disatukan dan diproses pada tengah malam. Karena itu Venmo dan Zelle populer di AS. Di Swiss pun transfer IBAN lambat, dan pembayaran real-time didominasi TWINT (dengan memindai QR code). BACS di Inggris juga lambat karena alasan yang sama
  • Di AS sebenarnya ada dua sistem transfer real-time: RTP dan FedNow. Bank yang ikut serta terus bertambah https://real-timepayments.com/Banks-Real-Time-Payments.html Dulu juga ada cara mengirim uang instan lewat jaringan kartu kredit dengan membayar biaya kecil. Hanya saja, kartu kredit punya aturan jaminan dan refund yang berbeda, dan saat terjadi penipuan kerugian bank juga lebih besar
  • Ini justru ada sisi baiknya bagi konsumen. Misalnya, ketika autodebit mencoba menarik uang dari rekening yang tidak punya saldo, bank akan memberi tahu lewat email beberapa kali. Jika semuanya real-time, itu langsung jadi masalah, tetapi dengan sistem sekarang kita masih punya waktu setelah menerima notifikasi untuk mengambil tindakan sendiri, sehingga bisa menghindari denda keterlambatan atau biaya tambahan. Karena transfer tidak instan, bank sempat memberi tahu dan saya sempat bereaksi
  • patio11 punya tulisan yang membahas ini dengan detail https://www.bitsaboutmoney.com/archive/the-long-shadow-of-checks/
• Tulisannya menarik dan memberi banyak bahan pemikiran. Saat kecepatan benar-benar terasa, yang penting bukan throughput aktual melainkan "rasa cepat", yaitu kecepatan yang terasa nyaman seperti respons UI atau input delay. Karena itu saya jadi lebih menyukai Go daripada Rust. Kecepatan kompilasi Go cukup tinggi sampai rasanya bahkan tidak perlu diukur. Sebaliknya, hal-hal yang lambat tetap tidak menyenangkan walaupun throughput aktualnya tinggi (seperti startup Java)
  • Bahkan saat membandingkan Go dan Rust, kecepatan kompilasi benar-benar terasa penting. Build Rust punya banyak dependency kecil yang macam-macam sehingga struktur proyeknya terasa mirip JavaScript. Go secara relatif punya dependency jauh lebih sedikit, dan saya suka itu
  • Developer boleh saja berdebat soal ini, tetapi yang sebenarnya penting adalah "bahasa mana yang lebih cepat bagi pengguna"
• Berlawanan dengan pernyataan "di software kita hampir tidak pernah mendengar 'tolong buat cepat'", hampir di setiap perusahaan tempat saya bekerja, kecepatan respons halaman dan latensi selalu menjadi prioritas tertinggi. Baik startup maupun perusahaan besar, kecepatan dan latensi adalah sasaran penting, dan seberapa cepat produk berjalan, seberapa cepat halaman muncul, serta apakah ada jeda aneh selalu jadi hal yang benar-benar diperhatikan
  • Di sebagian besar perusahaan yang saya alami langsung (6 dari 8), hampir tidak pernah ada waktu yang benar-benar diberikan untuk optimisasi performa, jadi saya selalu mengerjakannya diam-diam. Bahkan di tempat yang mengukur latensi dan mengaku itu penting pun, pada praktiknya hal itu sering didorong ke belakang oleh penambahan fitur
  • Sering kali mereka terobsesi mempercepat hasil pencarian, tetapi tidak terlalu peduli pada rendering halaman atau ukuran data yang dikirim ke pengguna
• Ini hal yang saya alami berulang kali di berbagai tempat kerja: kebanyakan orang meremehkan nilai nyata dari kecepatan. Mereka hanya mengasumsikan "workflow yang sama tetapi lebih cepat". Misalnya, mereka mengira mempercepat eksperimen besar yang berjalan semalaman tidak terlalu membantu, tetapi kalau kecepatannya ditingkatkan secara drastis, eksperimen itu bisa dijalankan beberapa kali di siang hari juga, dan ini menghasilkan tingkat produktivitas yang sama sekali berbeda
  • Orang sangat meremehkan biaya context switching. Mereka berpikir mengurangi sebuah perintah dari 30 detik menjadi 3 detik, jika hanya 10 kali sehari, berarti cuma menghemat 5 menit. Padahal, biaya perpindahan konteks yang sebenarnya jauh lebih besar
  • Setiap kali pipeline CI memakan waktu berjam-jam, saya selalu berpikir bahwa kalau selesai dalam 20 menit, saya pasti akan langsung memperbaiki bahkan warning lint kecil setiap kali itu muncul