Meski kesederhanaan punya keunggulan, sayangnya kompleksitas lebih mudah “dijual” (2022)
(eugeneyan.com)- Di balik rendahnya penilaian terhadap metode sederhana dalam peninjauan makalah atau evaluasi promosi ada bias kompleksitas, karena keluaran yang kompleks tampak seolah memuat lebih banyak upaya, keahlian, dan inovasi
- Sistem dengan banyak opsi dan komponen terlihat fleksibel, tetapi dalam operasi nyata bisa menjadi sulit dijelaskan, diuji, dan dipecahkan masalahnya, sehingga kesalahan dan inefisiensi dapat meningkat
- Ide dan sistem yang sederhana mudah dipahami, digunakan, diberi umpan balik, dan diperluas; saat diakuisisi pada 2012, Instagram melayani puluhan juta pengguna dengan tim 13 orang sambil tetap memakai teknologi teruji seperti PostgreSQL dan Redis
- Dalam machine learning pun teknik yang kompleks tidak selalu unggul; pada 45 dataset tabular berskala menengah, model berbasis pohon lebih baik daripada deep neural network, dan dalam rekomendasi serta pencarian ada kasus dot product lebih baik daripada neural collaborative filtering
- Jika kompleksitas itu sendiri diberi imbalan, hal ini mendorong kompleksitas yang tidak perlu dan kecenderungan not invented here; karena itu, semakin kompleks masalahnya, pertama-tama perlu ditimbang apakah solusi sederhana memungkinkan dan apakah biaya kompleksitasnya layak dibenarkan
Mengapa kompleksitas tampak lebih menarik
- Kompleksitas mudah diterima sebagai sinyal upaya
- Makalah dengan ide yang sulit dan banyak detail teknis tampak seolah membutuhkan banyak waktu dan usaha
- Sistem dengan banyak komponen dan fitur cenderung dinilai sebagai hasil kerja yang lebih serius dibanding sistem yang lebih kecil
- Kesan bahwa sesuatu sulit dibuat berfungsi seperti sinyal nilai dan kualitas
- Juga ditafsirkan sebagai sinyal keahlian
- Sistem dengan banyak bagian bergerak memberi kesan bahwa perancangnya mampu memahami dan mengintegrasikan setiap bagian
- Makalah dengan banyak istilah teknis dan pembuktian sulit didekati, tetapi justru tampak menunjukkan keahlian mendalam pada topiknya
- Praktik menanyakan algoritme dan struktur data yang hampir tidak dipakai dalam pekerjaan nyata saat wawancara juga terkait dengan sinyal semacam ini
- Ada pula persepsi bahwa kompleksitas adalah sinyal inovasi
- Makalah yang membuat arsitektur model sepenuhnya baru cenderung dinilai lebih baru daripada makalah yang memodifikasi jaringan yang sudah ada
- Sistem dengan banyak komponen yang dibuat dari nol tampak lebih orisinal daripada sistem yang memakai ulang komponen yang sudah ada
- Penilaian seperti “hanya mengubah satu hal dan sisanya sama dengan riset sebelumnya” dapat merendahkan nilai ide sederhana
- Semakin banyak fitur, semakin muncul ilusi bahwa sesuatu lebih komprehensif
- Sistem yang mendukung penyimpanan data SQL dan NoSQL sekaligus, atau memungkinkan pipeline batch dan streaming sekaligus, tampak seperti menangani semua kasus
- Semakin banyak balok Lego, semakin dianggap mampu merespons perubahan dengan baik
- Penilaian seperti ini mengarah pada complexity bias, yaitu preferensi berlebihan terhadap hal yang kompleks dibanding ide dan sistem sederhana
Titik ketika kesederhanaan menjadi keunggulan nyata
- Ide dan fitur sederhana mudah dipahami dan digunakan
- Kemungkinan adopsi dan dampak nyata meningkat
- Lebih mudah dikomunikasikan dan diberi umpan balik
- Sistem yang kompleks sulit dijelaskan dan dikelola, sehingga pengguna sulit memahami apa yang harus dilakukan dan bagaimana caranya
- Jika terlalu banyak hal yang harus disetel, kesalahan bertambah; jika terlalu banyak langkah, inefisiensi muncul
- Sistem sederhana lebih mudah dibuat dan diperluas
- Semakin sedikit komponen, semakin mudah implementasinya
- Jika memakai teknologi siap pakai yang terstandardisasi, lebih mudah menemukan orang untuk mengimplementasikan dan memeliharanya
- Kode dan interaksi internal berkurang, sehingga beban pemahaman dan pengujian juga turun
- Sistem yang rumit tanpa perlu membuat pembangunan memakan lebih banyak waktu dan sumber daya, sehingga menimbulkan pemborosan
- Kasus Instagram menunjukkan keunggulan pilihan teknologi yang sederhana
- Saat diakuisisi pada 2012, Instagram melayani puluhan juta pengguna dengan tim 13 orang
- Alih-alih teknologi tren terbaru, mereka mempertahankan teknologi teruji untuk menurunkan beban operasional per engineer
- Ketika startup lain mengadopsi penyimpanan data NoSQL yang sedang tren dan mengalami kesulitan, Instagram menggunakan PostgreSQL dan Redis yang mudah dipahami
Biaya operasional dan maintainability
- Deployment sistem bukanlah akhir, melainkan titik awal
- Sebagian besar upaya muncul setelah masuk ke produksi
- Operasi kemungkinan besar ditangani oleh orang lain, bukan tim yang awalnya membuatnya
- Sistem sederhana dapat menurunkan biaya pemeliharaan dan memperpanjang umur sistem
- Semakin sedikit bagian bergerak, semakin andal dan mudah diperbaiki
- Bagian yang dapat rusak berkurang
- Karena interaksi internal lebih sedikit, tiap komponen lebih mudah di-upgrade atau diganti
- Sistem kompleks punya banyak komponen yang harus dipahami oleh tim terbatas, sehingga biaya pemeliharaannya membesar
- Jika banyak bagian saling bergantung, troubleshooting juga menjadi lebih sulit
- Thomas Paine mengatakan dalam 『Common Sense』 bahwa “semakin sederhana sesuatu, semakin kecil kemungkinannya menjadi kacau, dan semakin mudah diperbaiki saat kekacauan terjadi”
Kasus ketika teknik sederhana tetap tidak kalah dalam machine learning
- Teknik yang lebih canggih tidak selalu menghasilkan performa lebih baik
- Tree-based models > deep neural networks: pada 45 dataset tabular berskala menengah, model berbasis pohon lebih baik daripada deep neural network
- Greedy algorithms > graph neural networks: pada masalah graf kombinatorial, greedy algorithm lebih baik daripada graph neural network
- Simple averaging ≥ complex optimizers: dalam masalah multi-task learning, rata-rata sederhana setara atau lebih baik daripada optimizer kompleks
- Simple methods > complex methods: dalam akurasi prediksi di 32 makalah, metode sederhana lebih baik daripada metode kompleks
- Dot product > neural collaborative filtering: dalam rekomendasi dan pencarian item, dot product lebih baik daripada neural collaborative filtering
Masalah yang muncul saat kompleksitas diberi imbalan
- Jika kompleksitas diberi imbalan, orang terdorong membuat hal yang rumit tanpa perlu
- Metode atau sistem sederhana bisa dinilai kurang bernilai hanya karena terlihat mudah
- Jika sistem dibuat kompleks demi mendapatkan imbalan, solusi paling sederhana tidak lagi menjadi pilihan yang jelas
- Kompleksitas melahirkan lebih banyak kompleksitas, dan akhirnya dapat membuat pekerjaan mencapai tingkat yang tidak mungkin dikerjakan
- Kecenderungan not invented here juga menguat
- Meski memakai ulang komponen yang sudah ada dapat menghemat waktu dan usaha, muncul kecenderungan untuk membuatnya dari nol
- Hal ini dapat membuang waktu dan sumber daya serta berujung pada hasil yang lebih buruk
- Dalam proses promosi dan peninjauan makalah machine learning, kompleksitas juga bisa ditekankan secara berlebihan
- Bryan Liles menunjukkan bahwa solusi sederhana lebih mudah diimplementasikan dan diperluas daripada solusi kompleks, tetapi promosi sering diberikan kepada orang yang membuat solusi kompleks
- Micah Goldblum mengatakan bahwa dalam review ML, komentar bahwa metode terlalu sederhana atau tersusun dari komponen yang sudah ada sering muncul, padahal kesederhanaan bukan kelemahan melainkan kekuatan
- Inovasi seperti Kalman Filters, PageRank, SVM, LSTM, Word2Vec, dan Dropout juga pernah ditolak
Cara yang lebih baik untuk menangani kompleksitas
- Tujuannya adalah menyelesaikan masalah kompleks dengan solusi sesederhana mungkin
- Fokus harus pada kompleksitas masalah, bukan kompleksitas solusi
- Solusi sederhana menunjukkan wawasan mendalam tentang masalah dan kemampuan menghindari solusi yang lebih kusut dan mahal
- Ini terhubung dengan ucapan Albert Einstein: “Segala sesuatu harus dibuat sesederhana mungkin, tetapi tidak lebih sederhana dari itu”
- Alih-alih solusi kompleks yang mencakup semuanya, beberapa solusi yang terfokus dapat dipertimbangkan
- Solusi serba guna (one-size-fits-all) bisa jadi kurang fleksibel dan kurang dapat digunakan ulang dibanding yang diharapkan
- Mendukung banyak use case dan stakeholder sekaligus membuat sistem terikat kuat, serta membutuhkan lebih banyak koordinasi untuk perencanaan dan migrasi
- Sistem dengan tujuan tunggal lebih mudah dioperasikan dan juga lebih mudah dibuang saat diperlukan
- Untuk mengurangi bias kompleksitas, Occam’s razor dapat diterapkan
- Prinsipnya adalah solusi atau penjelasan paling sederhana biasanya benar
- Jangan terlalu cepat menolak ide sederhana, atau menambahkan kompleksitas yang tidak perlu demi membenarkan nilainya
- Dengan mempertimbangkan biaya kompleksitas, perlu bertanya: “apakah ini sepadan?”
Bias kebalikan: memakai ulang kompleksitas yang sudah familier
- Di sisi berlawanan dari “not invented here” ada bias yang secara otomatis menyukai komponen yang sudah ada
- Karena sudah dikenal, terasa lebih mudah berdasarkan pengalaman pribadi, dan dapat mengurangi waktu serta usaha sendiri
- Namun jika komponen yang sudah ada itu sendiri sangat kompleks, memakainya dapat membuang lebih banyak waktu dan sumber daya serta menghasilkan hasil yang lebih buruk dibanding membuat sesuatu yang lebih sederhana dari awal
- Saat tidak ada opsi sederhana, membuat yang baru mungkin diperlukan
- Ada pula kasus ketika sesuatu yang baru dibuat tidak benar-benar menjadi sederhana, melainkan hanya menjadi benda lain yang sama kompleksnya dengan yang lama
- Sebagian masalah secara inheren kompleks dan memiliki essential complexity yang benar-benar tidak dapat dihilangkan
- ORM dibahas sebagai contoh buruk
- ORM terus dibuat ulang dan awalnya dimulai dengan sederhana, tetapi pada akhirnya kompleksitasnya meledak
- object/relational impedance mismatch sudah dikenal luas, dan ide ORM itu sendiri pada dasarnya kompleks
- Yang tampak mempertahankan kesederhanaan kemungkinan besar bukan ORM, melainkan query builder atau data mapper
- API cache PSR adalah contoh kompleksitas yang dapat dihilangkan
- Setelah API cache PSR-6, muncul API cache PSR-16 yang lebih sederhana
- PSR-16 mengurangi kompleksitas dan jumlah konsep, membuat API lebih kecil dan tidak terlalu opinionated
- Fakta bahwa adapter PSR-6 untuk implementasi PSR-16 dan adapter arah sebaliknya dapat dibuat menunjukkan bahwa kompleksitas yang dihilangkan dalam PSR-16 bukanlah kompleksitas esensial
- Sebagian library dan framework dapat tumbuh melampaui kompleksitas esensial atas nama developer experience
- Kesederhanaan nyata memiliki sifat yang dapat diukur dengan metrik seperti jumlah baris kode, jumlah public method, dan coupling
- Ada kasus ketika sebuah library tumbuh menjadi 10 kali ukuran awalnya dalam beberapa tahun dan mengeluarkan breaking change besar setiap 6–12 bulan
- Dorongan untuk menganggap library yang tidak bertumbuh sebagai “mati” dan pindah ke paket yang lebih “aktif” juga bisa menjadi gejala bias kompleksitas
- Untuk menghindari kompleksitas yang menyebar, terkadang pilihan membuat dari awal memang diperlukan
- Jika persyaratan dapat dikunci dan pertumbuhan scope yang melebar dapat dihindari, implementasi baru bisa menjadi pilihan yang lebih sederhana
- Perlu berhati-hati agar tidak memperkuat bias di salah satu sisi
1 komentar
Pendapat Hacker News
Saya pernah bekerja di salah satu perusahaan FAANG pada masa ketika menyelesaikan masalah kompleks dijadikan kriteria promosi; makin kompleks masalah yang diselesaikan, makin tinggi level, kompensasi, dan status yang didapat.
Secara alami orang-orang jadi mencari masalah kompleks yang layak dipecahkan, dan ketika perusahaan-perusahaan lain meniru ide perusahaan itu, tampaknya bahkan perusahaan kecil yang tidak membutuhkan solusi kompleks pun akhirnya memiliki stack teknologi serupa.
Belakangan saya memikirkan hal serupa saat melihat UI mobil, terutama UI yang kompleks dan sulit digunakan pada mobil listrik, sampai-sampai itu bisa membuat saya tidak membeli mobil yang mengharuskannya.
Kesimpulannya, konsumen yang berkelas dan konsumen aspiratif itu sangat berbeda, dan konsumen aspiratif jauh lebih banyak.
Jadi, secara ekonomi masuk akal untuk mengorbankan konsumen yang berkelas demi menyesuaikan diri dengan konsumen aspiratif.
Konsumen aspiratif menerima cacat dan tipu daya karena menganggapnya seperti simbol pencapaian konsumsi.
Kasarnya, mereka terlalu senang mengendarai mobil “mewah” sampai tidak melihat sampah yang ikut terbawa; sementara dari sudut pandang orang yang sudah membeli mobil mewah selama puluhan tahun, saya hanya ingin tuas persnelingnya mudah dikenali.
Target sentuhnya menjadi terlalu kecil tanpa alasan, dan sepertinya para pengembang membuat serta menguji UI di layar di atas meja yang diam atau di mobil yang tidak bergerak.
Di dalam mobil yang sedang bergerak, semuanya berantakan.
Mobil-mobil terbaru tanpa tuas persneling, lampu sein, wiper, dan lampu benar-benar kacau.
Karena dari kursi pengemudi Anda harus menusuk target kecil di layar yang bahkan tidak punya tempat untuk menaruh tangan, manipulasi tidak langsung, kebingungan, ketidakakuratan, dan distraksi membuat semua orang mengemudi lebih buruk.
Ia mengotomatiskan hal-hal merepotkan seperti mengunci dan membuka kunci, menutup jendela, memanaskan atau mendinginkan kabin lebih dulu, otomatis mengatur navigasi ke kantor pada pagi hari dan ke rumah pada malam hari, serta menyesuaikan kursi dan pengaturan berdasarkan kunci ponsel mana yang digunakan.
Berkat konektivitas gratis, navigasinya juga benar-benar berfungsi, sedangkan semua GPS bawaan mobil yang pernah saya pakai sebelumnya tidak berguna.
Layar pemilihan dan pemutaran musiknya juga bagus, dan perintah suara juga cukup bekerja dengan baik untuk memilih musik.
Tidak sempurna, tetapi menurut saya lebih baik daripada semua mobil bermesin pembakaran internal yang pernah saya kendarai.
Proses berangkat ke kantor pada pagi hari hanya butuh dua langkah: membuka pintu dan memasukkan mode berkendara.
Pada mobil bermesin pembakaran internal saat musim dingin, ada lebih dari 10 langkah: mencari kunci, membuka kunci mobil, membuka pintu, menyesuaikan kursi setelah istri mengemudi, menekan tombol start, menghilangkan embun beku dari kaca depan, menyalakan pemanas kaca belakang, mengikis es dari kaca depan, memilih kantor di GPS, melepas rem parkir, menekan kopling, lalu memasukkan gigi.
Orang-orang yang tidak memilikinya terus meratapi layar sentuh di internet, tetapi para pemilik Tesla tetap bertahan pada merek itu karena, terlepas dari ada tidaknya layar sentuh, mobilnya lebih baik daripada mobil lain.
Technology Connections baru-baru ini mengatakan dalam sebuah video bahwa untuk mengganti wiper, ia harus menahan tuas jelek bergaya tahun 90-an selama 4 detik, dan harus membaca manual untuk mengetahuinya.
Pada mobil yang dibuat dari komponen-komponen yang ditempel terpisah, perilaku sampah seperti ini sangat umum.
Sebaliknya, mobil saya mengirim notifikasi video pemantauan real-time ke ponsel, mengemudikan saya saat perjalanan ke kantor, dan untuk perpindahan gigi biasanya cukup mengenakan sabuk pengaman dan menginjak rem, lalu mobil memilih arah sendiri.
Fungsi penting dapat diakses secara kontekstual lewat roda kemudi, bukan lewat 50 tombol.
Sederhana sekaligus kuat, dan masalahnya ada pada eksekusi mobil-mobil mewah yang disebut sebelumnya yang sangat buruk.
Saya kadang menonton YouTuber bernama Theo Browne; ia terutama seorang developer frontend.
Saat melihatnya menjelaskan solusi, rasanya seperti kepala dipukul tongkat bisbol, dan jumlah elemen yang masuk ke demonya sampai membuat ingin menangis.
Saya juga terkejut dengan banyaknya istilah sulit terkait React yang ia sebut dalam satu video.
Saya tidak bermaksud menyudutkan orang tertentu, tetapi saya khawatir justru kompleksitas itulah yang membuatnya tetap populer.
Sebaliknya, Pieter Levels langsung mendorong PHP mentah ke produksi tanpa bicara soal Suspense, server-side rendering, atau Hydration.
Keduanya pada akhirnya mencapai tujuan yang sama, tetapi saya rasa Pieter Levels akan menghasilkan jauh lebih banyak uang, dan kesenjangan kompleksitasnya besar.
Faktanya, menurut saya sesuatu seperti Nomad List jauh lebih kaya fitur daripada yang saya lihat dari Theo.
Setelah itu saya melihat orang lain mengenalinya, lalu mereka berdebat dengan nada tinggi namun akrab tentang topik yang pernah Theo bahas dengan keras di kanalnya.
Kepribadiannya tampak sangat cocok untuk memaksimalkan keterlibatan media melalui kompleksitas yang tidak perlu.
Semakin kompleks, semakin banyak bahan perdebatan, dan bagi orang yang tidak akrab dengan opsi-opsi rumit, itu bisa membuatnya terlihat lebih pintar.
Jumlah library dan kode yang dipakai untuk contoh-contoh seperti mainan jauh lebih besar daripada yang saya lihat di produksi, dan saya pun pernah melihat sistem-sistem yang cukup mengerikan.
Saya tidak tahu ini akan bertahan berapa lama.
Banyak hal remeh yang tidak akan dipakai ikut terbawa, dan justru menghalangi bagian yang akan dipakai.
Saat terjadi masalah, kini Anda harus memahami bukan hanya bahasa pemrograman dan kode sendiri, tetapi juga kode di dalam framework pada jalur yang Anda lewati.
Jalur itu bisa dengan mudah turun hingga kedalaman 10–20 fungsi, dan sangat jarang ada dokumentasi yang cukup spesifik tentang apa yang terjadi pada berbagai kasus tepi.
Jumlah alat yang dipakai untuk membuat sesuatu yang relatif sederhana sangat besar, dan rasanya hal serupa juga terjadi di DevOps.
Masalah ini tampaknya diciptakan oleh para “developer frontend” di perusahaan.
Semacam rasa rendah diri terhadap “engineering sungguhan” yang dilakukan developer full-stack atau backend sepertinya membuat frontend juga ingin menciptakan masalah “engineering sungguhan”.
Selama puluhan tahun mengembangkan sistem legacy, saya sering melihat hal-hal—kadang dari desain perusahaan kami sendiri, kadang dari pekerjaan kontrak untuk klien—yang membuat saya percaya bahwa pelanggan tertentu memang lebih menyukai software yang kompleks dan penuh bug.
Alasannya, mereka bisa bersembunyi di baliknya.
Misalnya, “software-nya ada bug jadi tidak selesai tepat waktu”, “software-nya tidak mendukung Y jadi saya tidak bisa melakukan X”, atau “anjing memakan PR saya”.
Dalam banyak kasus, solusi yang sederhana, mudah, dan jauh lebih minim bug bisa saja dirancang, tetapi dengan begitu pengguna akan makin sulit menyembunyikan bahwa kegagalan tertentu mungkin bukan masalah software, melainkan ketidakmampuan mereka sendiri.
Jadi terutama di perusahaan yang tekanannya besar dari atas, para manajer justru benar-benar lebih suka bekerja dengan software yang tidak sepenuhnya mereka pahami, serta dikenal memiliki bug dan masalah.
Pada usia 27 tahun, ketika pindah dari pekerjaan pertama yang sudah saya jalani 5 tahun, saya mengganti program GUI yang sangat kompleks dengan GUI kecil yang membungkus dua program CLI.
Itu selalu berjalan bahkan jika input yang salah masuk, dan pada kegagalan yang jarang terjadi pun memberikan pesan error yang berguna.
Tiga perempuan yang memakainya benar-benar tidak menyukai saya.
Baru sekitar setahun setelah meninggalkan perusahaan itu saya memahami alasannya, dan saat itu saya memang tidak terlalu pintar.
Seiring waktu, saya jadi berpikir bahwa orang-orang menginginkan sesuatu seperti Microsoft Teams karena saat perlu, mereka bisa menjadikannya alasan untuk menutupi keterlambatan mereka.
Dalam UI fisik, kelompok kami menyebut ini masalah microwave.
Tidak ada yang memakai 20 tombol tambahan di microwave, dan kebanyakan orang hanya memakai satu atau dua tombol, tetapi tidak ada yang membeli microwave dengan tombol sedikit.
Saya sudah 10 tahun menyukai Samsung ME82V, dan dua kenop saja sudah cukup.
Jadi untuk ngemil diam-diam pukul 2 pagi, kita kembali seperti tahun 1999: berdiri mengawasi microwave.
Yang diinginkan hanyalah kenop kecepatan, sakelar pulse, dan sakelar daya, dan semua orang menginginkan itu, tetapi entah kenapa setiap generasi baru selalu ditambahi segudang fitur yang tidak dipakai siapa pun.
Tidak berarti selalu hanya dua tombol yang sama yang dipakai, jadi saya suka punya pilihan untuk memakai tombol lain.
Dan cukup sering, tombol yang banyak juga datang bersama spesifikasi yang lebih baik.
Kontrolnya lebih sedikit dan fiturnya lebih sedikit, tetapi pengalaman penggunanya luar biasa.
Saya ingat betapa rapinya iPod dibandingkan produk pesaing yang fiturnya berlebihan dan kompleks.
Keluhan seperti ini menyebalkan karena penuh dengan pepatah klise
Mengutip Einstein dan Dijkstra membuat orang mudah terlihat pintar, dan dengan keuntungan penilaian setelah kejadian serta ketidaktahuan terhadap kebutuhan nyata, mudah pula menggeneralisasi solusi yang kompleks lalu menunjuk-nunjuk kesalahan
“Sesederhana mungkin, tapi tidak lebih sederhana dari itu” memang selalu benar
Jika solusinya berantakan, berarti seharusnya dibuat lebih sederhana; jika solusi yang primitif menimbulkan masalah, berarti seharusnya tidak dibuat terlalu sederhana
Nadanya seperti bertanya kenapa tidak terpikir untuk membuatnya sempurna saja
Dalam kenyataan, ketika sebuah solusi punya banyak trade-off, bahkan menyepakati apa yang sederhana pun sangat sulit
Memelihara satu database yang kompleks bisa saja lebih mudah daripada memiliki tiga database yang “sederhana”, melakukan pekerjaan pengelolaan tiga kali lipat, lalu pada akhirnya harus mengimplementasikan sinkronisasi atau transaksi terdistribusi
Sesuatu yang mudah diimplementasikan sekarang bisa menciptakan masalah kompleks di kemudian hari, dan solusi siap pakai yang tidak menyelesaikan masalah sepenuhnya dapat melahirkan workaround rumit untuk kasus yang tidak didukung, lalu akhirnya menambahkan lagi kompleksitas migrasi ke solusi yang tepat
Nasihat “buat saja sederhana” sering kali tidak memahami bahwa solusi semacam itu bukan obat mujarab, dan bahwa dalam kenyataan jarang ada pilihan yang jelas antara kompleks versus sederhana
Proyek punya batasan seperti sistem lama yang berantakan, tuntutan hukum yang tidak konsisten, dan kebutuhan bisnis yang berubah-ubah; bisa juga memprioritaskan kecepatan rilis atau kemampuan yang bisa direkrut
Faktor ekonomi juga kejam: meski proses menerbitkan laporan tahunan terasa seperti mesin Rube Goldberg, kalau hanya dipakai setahun sekali, penulisan ulangnya mungkin tidak akan balik modal bahkan dalam 50 tahun
Pembahasan kompleksitas hampir tidak pernah mengakui bahwa proyek dan kebutuhan itu bertumbuh
Sesuatu yang sekarang sangat sederhana bisa menjadi kompleks di kemudian hari dengan cara yang sepenuhnya masuk akal, bukan karena ketidakmampuan atau niat buruk
Pada awalnya menyimpan data dalam file teks biasa itu sederhana dan indah, tetapi kemudian bisa berubah menjadi database NIH yang buruk
Namun memakai database sejak awal hanya untuk 3 baris data juga merupakan over-engineering
Refactoring punya biaya, jadi selalu memakai solusi ideal pun tidak sesederhana itu
Jauh lebih sedikit hal yang benar-benar jelas daripada yang kita kira
Menafsirkan “sesederhana mungkin, tapi tidak lebih sederhana dari itu” sebagai tuntutan akan kesempurnaan tidak mengikuti logika
Dalam praktik, kita tahu bahwa iterasi mengalahkan rencana
Jika sulit menyepakati apa yang sederhana, jangan minta izin; mintalah maaf nanti
Itu aturan yang berlaku di industri ini, dan mungkin juga di banyak industri lain
Jelas ada jenis kompleksitas kebetulan tertentu yang terlihat pada para pemimpi dan developer front-end
Kompleksitas itu rumit
Sistem yang lebih kompleks juga punya efek sekunder: menghasilkan banyak materi pendukung seperti tutorial dan video
Selain itu, bagi orang yang mempelajarinya, mereka menjadi pihak yang memiliki keterampilan dan tanggung jawab yang dibutuhkan perusahaan, sehingga memberi keamanan kerja dibandingkan sesuatu yang sekadar berjalan baik dan tidak membutuhkan orang seperti itu
Di IT ada terlalu banyak pekerjaan yang tidak akan ada jika perangkat lunak dibuat sederhana dan berjalan begitu saja
Dalam kasus sederhana, memang “jalan begitu saja”, asalkan Anda tidak mencoba melihat ke dalamnya atau melakukan sesuatu yang tidak sepele
Analogi itu mungkin cukup tepat
Kalau ini soal peninjauan makalah, sebagai reviewer yang saya cari dalam makalah bukan kesederhanaan ataupun kompleksitas, dan juga bukan “kebaruan”
Yang saya cari adalah analisis empiris yang menyeluruh dan merangsang pemikiran terhadap masalahnya
Di antara submission, banyak yang 1) mengusulkan sistem seperti Frankenstein yang menjahit belasan ide lama, lalu tanpa menganalisis secara mendalam pola kegagalan tiap bagiannya, berhasil mendapatkan “angka besar” dengan mengerahkan sebanyak mungkin mainan terbaru yang tersedia; 2) hanya sedikit mengubah metode lama dan kebetulan performanya membaik, tetapi tanpa justifikasi empiris maupun teoretis yang memadai tentang mengapa itu membantu
Tipe kedua mungkin punya sedikit sekali nilai bagi komunitas atau pembaca, tetapi menurut saya sebagian besar tidak berguna
Yang bernilai bagi pembaca adalah ketika seorang mahasiswa PhD menatap masalah cukup lama hingga mampu menghubungkan intuisinya dengan konfirmasi yang kuantitatif dan dapat diuji, serta memperoleh pengamatan yang dapat direproduksi dan punya daya prediksi
Misalnya, “kami memverifikasi secara eksperimental dalam semua kasus bahwa X memengaruhi Y melalui mekanisme Z yang dijelaskan dalam makalah ini, sehingga metrik A meningkat B%, dan ini konsisten dengan Z”
Terlepas dari kompleksitas, pernyataan seperti “kami melakukan X lalu A naik B%” tidak cukup
Sayangnya, tidak semua reviewer setuju
Guru sejarah SMA saya memberi tugas menulis esai tentang peristiwa-peristiwa yang mengarah ke Perang Dunia II
Pertanyaan pertama adalah berapa panjangnya, dan sang guru menjawab bahwa jika ada yang bisa membahas topik kompleks ini dalam satu halaman A4, ia akan memberi nilai penuh, tetapi ia sungguh meragukan apakah tulisan sesingkat itu bisa mencakupnya
Semua orang terkejut dengan logika itu
Tidak ada yang pernah mendengar guru mengatakan hal seperti itu, dan itu menunjukkan bahwa sejak kecil kita diajari bahwa lebih banyak selalu lebih baik
Penjelasan selalu bisa dibuat panjang atau pendek dengan memilih tingkat abstraksi, dan orang biasanya memilih tingkat itu berdasarkan konteks serta konvensi sosial
Misalnya “bagaimana penekanan tombol menjadi huruf di layar” bisa dijelaskan dalam satu kalimat, atau bisa menjadi beberapa buku panjang jika mencakup firmware, stack perangkat lunak, elektronika, ilmu material, dan proses manufaktur
Perang Dunia II juga bisa dikatakan dimulai ketika Hitler menginvasi Polandia dan France, bisa ditarik ke Perjanjian Versailles, atau bahkan sampai evolusi kehidupan di Bumi
Yang terakhir memang sok ilmiah, tetapi secara teknis benar bahwa itu adalah peristiwa yang mengarah ke Perang Dunia II
Saya sangat merekomendasikan ceramah Rich Hickey, Simple Made Easy
Kompleksitas sama sekali tidak laku dijual, tetapi hal yang mudah laku dijual
Jika perusahaan bisa merekrut banyak orang yang tahu cara memakai ‘foo’ dan industri terus membicarakan ‘foo’, mereka akan memilih foo meskipun foo benar-benar berantakan
Lihat saja arsitektur lambda, sebagian besar proyek Apache, container, dan sebagainya