Pilih Teknologi yang Membosankan (2015)

• Menahan diri dalam mengadopsi teknologi baru dan memprioritaskan teknologi yang sudah teruji (boring technology) lebih menguntungkan bagi kesuksesan jangka panjang perusahaan
• Setiap perusahaan pada dasarnya hanya memiliki sekitar 3 token inovasi (innovation tokens), dan setiap kali memilih NodeJS, MongoDB, atau alat yang baru lahir, satu token habis
• Teknologi yang sudah teruji memiliki fitur dan pola kegagalan (failure modes) yang sudah dipahami dengan baik, sehingga risiko hal-hal yang tidak diketahui bahwa itu tidak diketahui (unknown unknowns) yang khas pada teknologi baru menjadi lebih kecil
• Pilihan teknologi memengaruhi seluruh tim dan organisasi; karena beban operasional dan beban kognitif, alat yang cukup layak untuk berbagai masalah lebih menguntungkan daripada alat terbaik untuk tugas tertentu
• Pemilihan teknologi yang hati-hati memberi insinyur kebebasan untuk fokus pada masalah yang lebih besar, dan teknologi demi teknologi itu sendiri tidak ada gunanya

---

Menerima Kebosanan (Embrace Boredom)

• Setiap perusahaan memiliki sekitar 3 token inovasi (innovation tokens), dan pasokannya tetap untuk sementara waktu — sebagian bisa bertambah jika stabilitas dan kematangan sudah tercapai, tetapi orang cenderung melebih-lebihkan jumlah yang mereka miliki
• Menulis situs web dengan NodeJS, memakai MongoDB, atau mengadopsi teknologi service discovery yang dirilis kurang dari 1 tahun lalu masing-masing menghabiskan 1 token inovasi, sedangkan menulis database sendiri adalah jalan menuju masalah besar
  • Pilihan seperti ini mungkin masuk akal jika Anda adalah perusahaan konsultan javascript atau perusahaan basis data, tetapi kebanyakan justru mengejar misi besar seperti mendefinisikan ulang perdagangan global atau menciptakan ulang pembayaran web — menghabiskan perhatian yang terbatas untuk berinovasi di area seperti ssh adalah jalan pintas menuju kegagalan atau tertundanya keberhasilan
• "Membosankan (boring)" tidak sama dengan "buruk (bad)", dan ada juga teknologi yang membosankan sekaligus buruk — contoh yang membosankan tetapi cukup baik adalah MySQL, Postgres, PHP, Python, Memcached, Squid, Cron
• Kelebihan teknologi yang membosankan bukan hanya pada kemampuan (capabilities), tetapi juga karena pola kegagalan (failure modes)-nya sudah dipahami dengan baik
• Dalam memilih teknologi, ada known unknowns (misalnya perilaku basis data saat CPU mencapai 100% belum diketahui) dan unknown unknowns (misalnya tidak menyadari bahwa pencatatan statistik akan memicu jeda GC), dan semakin baru teknologinya, semakin besar skala unknown unknowns tersebut

Mengoptimalkan Secara Global (Optimize Globally)

• Preferensi pada teknologi yang membosankan adalah bias yang baik, tetapi bukan satu-satunya pertimbangan; pilihan teknologi memiliki cakupan (scope) yang memengaruhi tim, organisasi, dan keseluruhan sistem
• Menambah teknologi selalu ada biayanya — jika Anda sudah memakai Ruby lalu menambah Python, kompleksitasnya akan melampaui manfaat marjinal; namun dalam perdebatan Python vs Scala atau MySQL vs Redis, orang cenderung mengabaikan batasan dan meneriakkan "alat terbaik untuk tugas tersebut (best tool for the job)"
• Inti pekerjaan ini adalah memetakan masalah bisnis ke ruang solusi dari pilihan perangkat lunak; jika pilihan itu tanpa beban, kita bisa memilih alat yang optimal secara lokal untuk tiap masalah, tetapi di dunia nyata beban itu nyata
  • Beban tersebut adalah operasi (operations) dan, dalam tingkat yang lebih kecil, beban kognitif (cognitive overhead) — monitoring, unit test, pengetahuan yang dibutuhkan untuk memperbaiki sesuatu, skrip init, dan sebagainya cepat sekali menumpuk
• Masalah dari pola pikir "alat terbaik untuk tugas tersebut" adalah melihat "terbaik" dan "tugas" secara terlalu sempit — tugas yang sebenarnya adalah menjaga perusahaan tetap bertahan, dan alat yang "terbaik" adalah alat yang menempati posisi paling tidak buruk (least worst) untuk sebanyak mungkin masalah
• Biaya jangka panjang untuk menjaga sistem tetap stabil jauh lebih besar daripada ketidaknyamanan saat membangunnya, dan pengembang yang matang serta produktif memahami hal ini

Kadang-Kadang Memilih Teknologi Baru (Choose New Technology, Sometimes)

• Jika logika di atas didorong sampai ekstrem, hasilnya adalah membangun situs web hanya dengan Java, yang jelas tidak realistis — perlu ada cara untuk menambahkan alat baru ke kotak peralatan
• Pada akhirnya teknologi baru akan berdampak ke seluruh perusahaan, jadi penambahannya adalah keputusan yang memerlukan visibilitas tingkat perusahaan (company-wide visibility) — perlu ada ekspektasi budaya bahwa "ini adalah hal yang kita semua diskusikan bersama"
• Latihan yang paling direkomendasikan adalah bertanya pada diri sendiri bagaimana menyelesaikan masalah yang ada tanpa menambahkan teknologi baru — ini membantu mendeteksi situasi ketika "masalah" yang sebenarnya hanyalah seseorang ingin memakai teknologi tersebut, dan dalam kasus seperti itu harus segera dihentikan
  • Dengan jumlah pilihan teknologi yang sedikit pun Anda bisa melangkah jauh, dan jawaban yang sebenarnya biasanya bukan "tidak bisa", melainkan "bisa, tetapi terlalu sulit" — jika Anda merasa tujuan tidak bisa dicapai dengan sumber daya saat ini, mungkin Anda belum berpikir cukup kreatif
• Akan sangat membantu jika mencatat dengan jelas mengapa menyelesaikan masalah itu di stack saat ini terlalu mahal dan terlalu sulit
• Memilih teknologi baru bisa berupa penambahan murni (misalnya menambahkan memcached karena belum ada caching), atau bisa tumpang tindih dengan yang sudah ada atau menggantikannya — jika itu penggantian, perlu ada ekspektasi yang jelas tentang migrasi fungsi yang ada, dan kebijakannya biasanya berupa "berjanji melakukan migrasi" bersama jadwal yang diusulkan
  • Tujuannya adalah menjaga puing-puing tetap pada tingkat yang bisa dikelola dan mencegah menjamurnya solusi yang optimal secara lokal
• Prosedur ini tidak memberatkan; hanya beberapa pertanyaan untuk diisi sebagai tugas dan satu rapat untuk membahasnya — jika teknologi atau layanan baru lolos dari gerbang ini tanpa masalah, maka penambahannya memang tepat

Langsung Rilis Saja (Just Ship)

• Pemrograman poliglot (polyglot programming) dijual dengan janji bahwa memberi pengembang kebebasan penuh memilih alat akan membuat penyelesaian masalah lebih efektif, tetapi ini paling baik hanyalah definisi masalah yang naif, dan paling buruk adalah penalaran yang saling menguatkan — toil dari operasi sehari-hari akan membebani pengembang
• Justru pemilihan teknologi yang hati-hati memberi insinyur kebebasan untuk memikirkan pertanyaan yang lebih besar, dan teknologi demi teknologi itu sendiri adalah minyak ular

Kasus Etsy (Catatan kaki)

• Etsy sangat menderita karena masalah ini di awal — setelah merekrut banyak programmer Python, mereka lalu mencari-cari pekerjaan untuk mereka dan membuat lapisan tengah yang tidak bermakna, dan butuh bertahun-tahun untuk menghapusnya / pada saat yang sama latensi pencarian persentil ke-90 sekitar 2 menit — Etsy memang tidak gagal, tetapi tidak bisa merilis apa pun selama bertahun-tahun sehingga keberhasilannya tertunda
• Irisan antara teknologi yang membosankan dan buruk sering disebut "enterprise software", tetapi ini bisa jadi tidak akurat
• Contoh activity feeds di Etsy - diimplementasikan ketika sebagian besar sistem mereka disatukan dengan PHP, MySQL, Memcached, dan Gearman / implementasinya jauh lebih rumit dibanding memakai alat seperti Redis, tetapi tetap bisa dibangun dengan stack tersebut
  • Selama beberapa tahun berikutnya perhatian berpindah ke tempat lain, tetapi penggunaan activity feeds meningkat 20 kali lipat; berkat platform bersama, semuanya tetap berjalan normal tanpa perubahan khusus — ini adalah keuntungan jangka panjang dari pengendalian diri dalam memilih teknologi
  • Namun ini bukan absolutisme — activity feeds berbasis memcached dianggap praktis, tetapi Etsy tidak sampai mengimplementasikan pencarian penuh dengan pencarian berfaset murni dalam PHP, sehingga mereka memakai Solr