Anda Bukan Google (You Are Not Google)
(blog.bradfieldcs.com)Banyak software engineer tidak rasional dalam memilih teknologi. Saat memilih teknologi baru, mereka sering mengikutinya hanya karena teknologi itu digunakan oleh perusahaan big tech seperti Google atau Amazon, tanpa kebutuhan nyata atau definisi masalah yang jelas. Misalnya, MapReduce dan Hadoop lahir untuk pemrosesan data berskala besar, tetapi ketika perusahaan yang sebenarnya tidak memiliki skala data sebesar itu mengadopsinya, mereka justru mengalami biaya I/O yang tidak perlu dan kehilangan fungsionalitas. Ini hanyalah fenomena "pemujaan teknologi (cargo cult)".
Tulisan ini mengajukan checklist bernama UNPHAT untuk menghindari peniruan yang tidak kritis seperti itu:
Understand – pahami masalah secara menyeluruh.
eNumerate – daftar berbagai kandidat yang mungkin.
Paper – baca paper atau white paper yang menjadi dasar teknologi tersebut.
Historical context – lihat konteks historis saat teknologi itu dikembangkan.
Advantages – bandingkan kelebihan dan kekurangannya secara seimbang.
Think – pikirkan sendiri apakah teknologi ini benar-benar cocok untuk masalahnya.
Tulisan tersebut juga memberikan contoh teknologi seperti Cassandra, Kafka, dan SOA (Service-Oriented Architecture) yang diadopsi tanpa kritik dalam situasi yang tidak sesuai dengan use case nyatanya. Misalnya, Kafka dibuat untuk LinkedIn yang memproses jutaan pesan per detik, tetapi ada juga perusahaan kecil yang memakainya meski hanya memiliki puluhan transaksi per hari.
Penulis juga menekankan bahwa bahkan Google sendiri berhenti menggunakan MapReduce ketika mereka menilai teknologi itu sudah tidak lagi cocok. Pada akhirnya, yang penting bukanlah teknologinya, melainkan memahami dengan tepat masalah yang ingin Anda selesaikan dan memilih teknologi yang sesuai.
Terakhir, penulis menyebut bahwa Pólya, Hamming, Rich Hickey, dan lainnya juga terus mengulang pesan yang sama. Intinya sederhana:
“Berpikirlah. Dan pahami masalah yang sebenarnya.”
15 komentar
Saya masuk ke sini karena kebetulan muncul di rekomendasi Google, dan artikel ini ditulis terlalu dari sudut pandang Geek. Dari sudut pandang bisnis, ini sama sekali bukan cerita yang tepat. Kenapa begitu?
Tool besar yang dipakai big tech memudahkan pencarian tenaga ahli.
Banyak orang mempelajarinya untuk bisa masuk ke big tech, dan banyak juga yang belajar karena big tech memilihnya. Tentu saja, jadi lebih mudah mencari orang yang paham soal ini, dan juga lebih mudah mencari orang berpengalaman atau ahli. Namun, bagaimana kalau tool itu benar-benar baru bagi kita? Bukan berarti tidak ada orang yang mendalaminya, tetapi akan jauh lebih sulit mencari orang seperti itu dibandingkan ahli untuk tool milik big tech.
Tool besar yang digunakan big tech punya referensi dan materi yang melimpah
Tool besar yang dipakai banyak orang punya banyak materi untuk menyelesaikan masalah, dan hasil pencarian Google-nya juga melimpah. Sebagian besar masalah biasanya juga pernah dialami orang lain, sehingga dengan pencarian sederhana kita bisa dengan mudah memahami masalahnya. Namun, untuk masalah pada tool yang belum familiar, referensinya sulit ditemukan, dan jika masalah terjadi, kemungkinan besar akan memakan banyak waktu untuk mengidentifikasi penyebabnya. Padahal semua itu biaya. Apakah masalah ini berasal dari tool kecil yang baru diadopsi? Atau kita sedang salah paham dan mengira masalahnya ada di sana, padahal sebenarnya dari sisi lain?
Justru big tech lebih mudah melakukan peralihan seperti ini. Karena skala pemrosesan data mereka sangat besar, sedikit keuntungan I/O pun bisa menjadi keuntungan yang besar. Dan ada banyak orang yang terdorong untuk mempelajarinya hanya karena big tech mengadopsinya. Namun, di perusahaan kecil dan menengah, karena skala datanya relatif kecil, sedikit keuntungan I/O tidak memberikan manfaat sebesar itu, sementara masalah di atas sangat serius. Jumlah orang yang mau belajar solusi yang diadopsi perusahaan kecil dan menengah juga sedikit. Karena itu, bagi pelaku usaha skala kecil dan menengah, alih-alih memperdebatkan hal seperti ini layaknya seorang Geek, sering kali kesimpulannya justru lebih ekonomis untuk mengikuti tool yang dipakai big tech.
Setelah membaca artikel aslinya, ternyata ini tulisan yang dibuat pada 2017.
Sudah 8 tahun berlalu sejak itu, dan mengejutkan bahwa isi ini masih tetap relevan.
Saya sangat setuju dengan isi di atas!
Namun, menurut saya, kasus overengineering di perusahaan kecil juga terjadi karena orang-orang yang menargetkan perusahaan besar ingin membangun pengalaman dengan tool semacam itu di perusahaan kecil.
Tentu saja, CEO mungkin tidak terlalu menyukainya haha
Bukankah 80% alasan alat yang disesuaikan dengan kebutuhan perusahaan besar akhirnya dipakai begitu saja di perusahaan kecil adalah ini? Yang seharusnya mengendalikan hal itu adalah CTO, tetapi ada juga kasus ketika CTO-nya sendiri sedang mempertimbangkan pindah kerja ke perusahaan besar.
Kalau pekerjaan yang harus dilakukan tidak banyak, biasanya jadi melakukan hal-hal yang tidak perlu hehe
Bahkan masalah yang mudah pun dibuat sulit supaya terlihat seperti sudah melakukan sesuatu. Kalau dibuat sederhana, banyak juga orang yang mengira itu memang mudah.. hahahaha
Karena takut hal yang dibuat kecil akan sulit diperbaiki menjadi besar nanti, ada kalanya orang justru membuatnya besar sejak awal...
Saya rasa tulisan ini juga berlaku untuk K8s. Jadi teringat buku "Cara Menulis Kode agar Sulit Dipelihara". Haha
Pada akhirnya, kita harus memahami masalah yang ingin diselesaikan oleh teknologi-teknologi tersebut, serta konteks yang melatarbelakangi kemunculannya. Contoh yang disebutkan dalam tulisan antara lain sebagai berikut.
Apakah masalah yang ingin mereka selesaikan selaras dengan masalah yang ingin saya selesaikan? Menurut saya, hal itu perlu dicermati dengan baik.
Oh, saya sangat setuju. Ini mengingatkan saya bahwa saat membimbing mahasiswa/junior, saya sering memberi saran agar mereka mencoba memahami sejarah teknologi.
Sepertinya cukup banyak orang yang kadang lupa bahwa teknologi adalah alat, bukan tujuan.
Begitu sesuatu menjadi syarat utama dalam memilih teknologi hanya karena sudah terverifikasi di big tech atau karena sedang banyak dipakai belakangan ini, kenaikan biaya yang tidak perlu pun cenderung mengikuti dengan sendirinya.
Di Korea, budaya cargo cult terhadap Spring memang kuat.
Musim semi membuat perekrutan tenaga kerja jadi lebih mudah...
Di Korea, spring lebih merupakan hibrida yang terbentuk bukan karena pemujaan..
melainkan karena besarnya ketidakmampuan pemerintah dan rasa malas para developer..
Saya sangat setuju. Pada akhirnya, Spring juga hanyalah alat untuk memecahkan masalah.
Brainstorming, mind map, deep learning, waktu kerja riset berkurang, efeknya ada karena zerg jangka panjang Juli, pengingat saya.